Archived issue #0027892
Construction error in offset
Description
The changes made in #0026329 lead to regression on test offset with_intersect J9: offset algorithm crashes with exception Standard_ConstructionError "BRepOffset_MakeOffset::TrimEdge no projection". The exception is generated in BRepOffset_MakeOffset.cxx, at line 1056, due to the fact that point being projected is not located on the curve. The point here has coordinates (0,0,0), which indicates that it has not been initialized. Apparently this highlights some flaw in the algorithm.
Steps to reproduce
Public activity
23 archived notes
Participants are labeled by their role within this record.
Branch [archived branch] has been created by Participant.
[revision removed]
Detailed log of new commits:
Author: nbv
Date: Tue Sep 27 12:21:24 2016 +0300
0027892: Construction error in offset
Field Geom_OffsetSurface::myOscSurf was lost when trimming offset-surface. This problem has been solved while fixing.
Author: ifv
Date: Tue Aug 9 20:12:59 2016 +0300
0026329: Restore floating point signals handling in DRAW
Added DRAW command dsetsignal, resetting OSD signal handler with either armed or disabled FPE handler, according to an option.
If called without arguments, it sets FPE handler only if environment variable OSD_FPE is defined (with value different from 0).
On start, DRAW calls dsetsignal to set FPE signal if CSF_FPE is defined.
Test bugs fclasses bug6143 uses dsetsignal to set FPE handler unconditionally before the test command, and resets it to default at the end.
A number of changes in the code have been done in order to fix floating point exceptions that became generated after enabling signals:
- Global functions Sinh() and Cosh() defined in Standard_Real.hxx are improved to raise Standard_NumericError exception if argument is too big (greater than 710.47586), instead of relying on system treatment of floating point overflow. These functions are used instead of sinh and cosh in ElCLib.cxx.
- Maximal value of parameter on hyperbola is restricted by 23 (corresponding to ~1e10 in 3d) in order to avoid FP overflow in Extrema_GenExtCS.cxx, ShapeFix_EdgeProjAux.cxx.
- Interface of the root curve adaptor class Adaptor3d_Curve has been updated to add new virtual methods BasisCurve and OffsetValue. They complement the adaptor for the case of offset curves. These methods are used in Extrema_GenExtCS.cxx to restrict domain search in the case of offset of hyperbola, in order to get rid of floating point overflow. All classes inheriting Adaptor3d_Curve have been changed to implement the new virtual methods.
- Protection against division by zero has been implemented in ApproxInt_KnotTools.cxx, BRepClass3d_SClassifier.cxx, BRepGProp_Face.cxx, BRepMesh_FastDiscretFace.cxx, Geom2dGcc_Circ2d2TanOnIter.cxx, Geom2dInt_Geom2dCurveTool.cxx, IntPolyh_MaillageAffinage.cxx.
- Protection against calling of math functions of infinite arguments has been added in BRepCheck_Edge.cxx, BRepLib.cxx, CSLib_NormalPolyDef.cxx, Extrema_FuncExtPC.gxx, Extrema_GExtPC.gxx, Extrema_GLocateExtPC.gxx, Intf_InterferencePolygonPolyhedron.gxx, ShapeAnalysis_Surface.cxx, ShapeAnalysis_TransferParametersProj.cxx, ShapeAnalysis_Wire.cxx, math_FunctionSetRoot.cxx.
- Proper initialization of local variables is done in BOPAlgo_PaveFiller_6.cxx, XSDRAWSTLVRML.cxx.
- Inconsistent usage of Standard_Boolean* to access integer data in HLR (caused by #0027772) is corrected
Some test cases have been updated to actual state.
[revision removed]
Detailed log of new commits:
Author: nbv
Date: Tue Sep 27 12:21:24 2016 +0300
0027892: Construction error in offset
Field Geom_OffsetSurface::myOscSurf was lost when trimming offset-surface. This problem has been solved while fixing.
Author: ifv
Date: Tue Aug 9 20:12:59 2016 +0300
0026329: Restore floating point signals handling in DRAW
Added DRAW command dsetsignal, resetting OSD signal handler with either armed or disabled FPE handler, according to an option.
If called without arguments, it sets FPE handler only if environment variable OSD_FPE is defined (with value different from 0).
On start, DRAW calls dsetsignal to set FPE signal if CSF_FPE is defined.
Test bugs fclasses bug6143 uses dsetsignal to set FPE handler unconditionally before the test command, and resets it to default at the end.
A number of changes in the code have been done in order to fix floating point exceptions that became generated after enabling signals:
- Global functions Sinh() and Cosh() defined in Standard_Real.hxx are improved to raise Standard_NumericError exception if argument is too big (greater than 710.47586), instead of relying on system treatment of floating point overflow. These functions are used instead of sinh and cosh in ElCLib.cxx.
- Maximal value of parameter on hyperbola is restricted by 23 (corresponding to ~1e10 in 3d) in order to avoid FP overflow in Extrema_GenExtCS.cxx, ShapeFix_EdgeProjAux.cxx.
- Interface of the root curve adaptor class Adaptor3d_Curve has been updated to add new virtual methods BasisCurve and OffsetValue. They complement the adaptor for the case of offset curves. These methods are used in Extrema_GenExtCS.cxx to restrict domain search in the case of offset of hyperbola, in order to get rid of floating point overflow. All classes inheriting Adaptor3d_Curve have been changed to implement the new virtual methods.
- Protection against division by zero has been implemented in ApproxInt_KnotTools.cxx, BRepClass3d_SClassifier.cxx, BRepGProp_Face.cxx, BRepMesh_FastDiscretFace.cxx, Geom2dGcc_Circ2d2TanOnIter.cxx, Geom2dInt_Geom2dCurveTool.cxx, IntPolyh_MaillageAffinage.cxx.
- Protection against calling of math functions of infinite arguments has been added in BRepCheck_Edge.cxx, BRepLib.cxx, CSLib_NormalPolyDef.cxx, Extrema_FuncExtPC.gxx, Extrema_GExtPC.gxx, Extrema_GLocateExtPC.gxx, Intf_InterferencePolygonPolyhedron.gxx, ShapeAnalysis_Surface.cxx, ShapeAnalysis_TransferParametersProj.cxx, ShapeAnalysis_Wire.cxx, math_FunctionSetRoot.cxx.
- Proper initialization of local variables is done in BOPAlgo_PaveFiller_6.cxx, XSDRAWSTLVRML.cxx.
- Inconsistent usage of Standard_Boolean* to access integer data in HLR (caused by #0027772) is corrected
Some test cases have been updated to actual state.
Branch [archived branch] has been updated forcibly by Participant.
[revision removed]
[revision removed]
Dear Mikhail,
Please review CR27892 branch.
Test cases "offset with_intersect J9" and "offset with_intersect_80 K8" have been reverted to their state on the MASTER.
Please review CR27892 branch.
Test cases "offset with_intersect J9" and "offset with_intersect_80 K8" have been reverted to their state on the MASTER.
Please, make all changes only in OffsetSurface, without changing its API, as we agreed.
Branch [archived branch] has been created by Participant.
[revision removed]
Detailed log of new commits:
Author: nbv
Date: Tue Sep 27 17:46:14 2016 +0300
0027892: Construction error in offset
Field Geom_OffsetSurface::myOscSurf was lost when trimming offset-surface. This problem has been solved while fixing.
[revision removed]
Detailed log of new commits:
Author: nbv
Date: Tue Sep 27 17:46:14 2016 +0300
0027892: Construction error in offset
Field Geom_OffsetSurface::myOscSurf was lost when trimming offset-surface. This problem has been solved while fixing.
Done!
Dear Mikhail,
Please review CR27892_1 branch.
Dear Mikhail,
Please review CR27892_1 branch.
Branch [archived branch] has been updated forcibly by Participant.
[revision removed]
[revision removed]
I have corrected the commit message.
Reviewed.
Please test.
Reviewed.
Please test.
Branch [archived branch] has been updated forcibly by Participant.
[revision removed]
[revision removed]
Method Value for Geom_OffsetSurface uses field myOscSurf in case when the normal to basis surface is small. If myOscSurf is null then the value is computed by another algorithm and (in most cases) has become wrong.
As result, earlier (when myOscSurf was not initialized) intersection result of two offset surfaces (indeed, offset surfaces are not intersected; they are converted to B-spline before intersection algorithm launching) was wrong (section edge was incorrect). Therefore, in place of the code where the common vertex of two edges (at least, one of them is intersection edge) is taken, wrong vertex is returned. It was the reason of described exception.
After the fix, correct surfaces are intersected and the result is correct (section) edge. Therefore, all common vertices are found correctly.
P.S.
On the current MASTER, field myOscSurf is initialized correctly even for trimmed surface. The reason, why it is not after the fix #0026329 is not investigated.
As result, earlier (when myOscSurf was not initialized) intersection result of two offset surfaces (indeed, offset surfaces are not intersected; they are converted to B-spline before intersection algorithm launching) was wrong (section edge was incorrect). Therefore, in place of the code where the common vertex of two edges (at least, one of them is intersection edge) is taken, wrong vertex is returned. It was the reason of described exception.
After the fix, correct surfaces are intersected and the result is correct (section) edge. Therefore, all common vertices are found correctly.
P.S.
On the current MASTER, field myOscSurf is initialized correctly even for trimmed surface. The reason, why it is not after the fix #0026329 is not investigated.
Dear BugMaster,
Branch CR27892_1 from occt git-repository (and master from products git-repository) was compiled on Linux, MacOS and Windows platforms and tested on Release mode.
[revision removed]
Number of compiler warnings:
occt component :
Linux: 0 (0 on master)
Windows: 0 (0 on master)
MacOS : 0 (0 on master)
products component :
Linux: 64 (64 on master)
Windows: 0 (0 on master)
MacOS : 1133
Regressions/Differences/Improvements:
http://occt-tests/CR27892_1-master-OCCT/Debian70-64/bugs/modalg_4/bug8842_8.html
http://occt-tests/CR27892_1-master-OCCT/Windows-64-VC10/bugs/modalg_4/bug8842_8.html
bugs modalg_4 bug8842_8: FAILED
http://occt-tests/CR27892_1-master-Products/Debian70-64/emesh/bugs/bug26326_1.html
http://occt-tests/CR27892_1-master-Products/Windows-64-VC10/emesh/bugs/bug26326_1.html
emesh bugs bug26326_1: IMPROVEMENT
Testing cases:
http://occt-tests/CR27892_1-master-OCCT/Debian70-64/offset/with_intersect_20/J9.html
http://occt-tests/CR27892_1-master-OCCT/Windows-64-VC10/offset/with_intersect_20/J9.html
offset with_intersect_20 J9: BAD (known problem)
http://occt-tests/CR27892_1-master-OCCT/Debian70-64/offset/with_intersect_80/J9.html
http://occt-tests/CR27892_1-master-OCCT/Windows-64-VC10/offset/with_intersect_80/J9.html
offset with_intersect_80 J9: BAD (known problem)
Testing on Linux:
occt component :
Total MEMORY difference: 90980156 / 90236020 [+0.82%]
Total CPU difference: 19329.229999999854 / 19249.509999999875 [+0.41%]
products component :
Total MEMORY difference: 30024241 / 30053704 [-0.10%]
Total CPU difference: 5111.049999999978 / 5152.219999999975 [-0.80%]
Testing on Windows:
occt component :
Total MEMORY difference: 57216986 / 57221541 [-0.01%]
Total CPU difference: 17950.73866809867 / 18310.78897609872 [-1.97%]
products component :
Total MEMORY difference: 21272053 / 21235672 [+0.17%]
Total CPU difference: 4901.832221799954 / 4988.631178199945 [-1.74%]
There are following differences in images found by testdiff.
http://occt-tests/CR27892_1-master-OCCT/Windows-64-VC10/diff-Windows-64-VC10-image.html
IMAGE bugs modalg_4 bug8842_8: bug8842_8.png differs
http://occt-tests/CR27892_1-master-Products/Windows-64-VC10/diff-Windows-64-VC10-image.html
IMAGE emesh bugs bug26326_1: bug26326_1.png differs
Branch CR27892_1 from occt git-repository (and master from products git-repository) was compiled on Linux, MacOS and Windows platforms and tested on Release mode.
[revision removed]
Number of compiler warnings:
occt component :
Linux: 0 (0 on master)
Windows: 0 (0 on master)
MacOS : 0 (0 on master)
products component :
Linux: 64 (64 on master)
Windows: 0 (0 on master)
MacOS : 1133
Regressions/Differences/Improvements:
http://occt-tests/CR27892_1-master-OCCT/Debian70-64/bugs/modalg_4/bug8842_8.html
http://occt-tests/CR27892_1-master-OCCT/Windows-64-VC10/bugs/modalg_4/bug8842_8.html
bugs modalg_4 bug8842_8: FAILED
http://occt-tests/CR27892_1-master-Products/Debian70-64/emesh/bugs/bug26326_1.html
http://occt-tests/CR27892_1-master-Products/Windows-64-VC10/emesh/bugs/bug26326_1.html
emesh bugs bug26326_1: IMPROVEMENT
Testing cases:
http://occt-tests/CR27892_1-master-OCCT/Debian70-64/offset/with_intersect_20/J9.html
http://occt-tests/CR27892_1-master-OCCT/Windows-64-VC10/offset/with_intersect_20/J9.html
offset with_intersect_20 J9: BAD (known problem)
http://occt-tests/CR27892_1-master-OCCT/Debian70-64/offset/with_intersect_80/J9.html
http://occt-tests/CR27892_1-master-OCCT/Windows-64-VC10/offset/with_intersect_80/J9.html
offset with_intersect_80 J9: BAD (known problem)
Testing on Linux:
occt component :
Total MEMORY difference: 90980156 / 90236020 [+0.82%]
Total CPU difference: 19329.229999999854 / 19249.509999999875 [+0.41%]
products component :
Total MEMORY difference: 30024241 / 30053704 [-0.10%]
Total CPU difference: 5111.049999999978 / 5152.219999999975 [-0.80%]
Testing on Windows:
occt component :
Total MEMORY difference: 57216986 / 57221541 [-0.01%]
Total CPU difference: 17950.73866809867 / 18310.78897609872 [-1.97%]
products component :
Total MEMORY difference: 21272053 / 21235672 [+0.17%]
Total CPU difference: 4901.832221799954 / 4988.631178199945 [-1.74%]
There are following differences in images found by testdiff.
http://occt-tests/CR27892_1-master-OCCT/Windows-64-VC10/diff-Windows-64-VC10-image.html
IMAGE bugs modalg_4 bug8842_8: bug8842_8.png differs
http://occt-tests/CR27892_1-master-Products/Windows-64-VC10/diff-Windows-64-VC10-image.html
IMAGE emesh bugs bug26326_1: bug26326_1.png differs
Dear msv,
Branch [archived branch] has been rejected due to:
- regressions/differences/improvements
- differences in images
Branch [archived branch] has been rejected due to:
- regressions/differences/improvements
- differences in images
About the regression in "bugs modalg_4 bug8842_8" test case.
By the reason described in the issue #0027929, intersection between two offset surfaces cannot be found:
Draw[]> restore Attachment 1 (BREP)
Draw[]> restore Attachment 2 (BREP)
Draw[]> bsection rr f1 f4
Draw[]> nbs rr
# FIX: VERTEX : 4; EDGE : 2
# MASTER: VERTEX : 2; EDGE : 1
Draw[9]> lprops rr 1.0e-4
# FIX: 0.0199311
# MASTER: 87.8157
See Attachment 3 (PNG) and Attachment 4 (PNG) attached pictures in order to understand differences (on the fix, ZOOM is required in order to see section result). As result, on the fix, the offset shell cannot be built correctly.
This situation should be fixed in frame of the issue #0027929.
By the reason described in the issue #0027929, intersection between two offset surfaces cannot be found:
Draw[]> restore Attachment 1 (BREP)
Draw[]> restore Attachment 2 (BREP)
Draw[]> bsection rr f1 f4
Draw[]> nbs rr
# FIX: VERTEX : 4; EDGE : 2
# MASTER: VERTEX : 2; EDGE : 1
Draw[9]> lprops rr 1.0e-4
# FIX: 0.0199311
# MASTER: 87.8157
See Attachment 3 (PNG) and Attachment 4 (PNG) attached pictures in order to understand differences (on the fix, ZOOM is required in order to see section result). As result, on the fix, the offset shell cannot be built correctly.
This situation should be fixed in frame of the issue #0027929.
emesh bugs bug26326_1: IMPROVEMENT
On the my machine, the situation is the same as on the MASTER.
On the my machine, the situation is the same as on the MASTER.
Branch [archived branch] has been created by Participant.
[revision removed]
Detailed log of new commits:
Author: nbv
Date: Tue Sep 27 17:46:14 2016 +0300
0027892: Construction error in offset
Provide proper initialization of the field Geom_OffsetSurface::myOscSurf in the case of creating offset of the trimmed bspline surface.
Adjusting test cases according to their new behavior.
[revision removed]
Detailed log of new commits:
Author: nbv
Date: Tue Sep 27 17:46:14 2016 +0300
0027892: Construction error in offset
Provide proper initialization of the field Geom_OffsetSurface::myOscSurf in the case of creating offset of the trimmed bspline surface.
Adjusting test cases according to their new behavior.
Dear Mikhail,
Please review CR27892_2 branch. Only test case has been corrected.
Please review CR27892_2 branch. Only test case has been corrected.
Reviewed. However, I recommend to postpone integration of this fix till resolution of #0027929.
Dear BugMaster,
Branch CR27892_2 from occt git-repository (and master from products git-repository) was compiled on Linux, MacOS and Windows platforms and tested on Release mode.
[revision removed]
Number of compiler warnings:
occt component :
Linux: 0 (0 on master)
Windows: 0 (0 on master)
MacOS : 0 (0 on master)
products component :
Linux: 64 (64 on master)
Windows: 0 (0 on master)
MacOS : 1132
Regressions/Differences/Improvements:
No regressions/differences
Testing cases:
http://occt-tests/CR27892_2-master-OCCT/Debian70-64/offset/with_intersect_20/J9.html
http://occt-tests/CR27892_2-master-OCCT/Windows-64-VC10/offset/with_intersect_20/J9.html
offset with_intersect_20 J9: BAD (known problem)
http://occt-tests/CR27892_2-master-OCCT/Debian70-64/offset/with_intersect_80/J9.html
http://occt-tests/CR27892_2-master-OCCT/Windows-64-VC10/offset/with_intersect_80/J9.html
offset with_intersect_80 J9: BAD (known problem)
Testing on Linux:
occt component :
Total MEMORY difference: 90808033 / 90432455 [+0.42%]
Total CPU difference: 19343.93999999981 / 19274.589999999782 [+0.36%]
products component :
Total MEMORY difference: 29998286 / 30036359 [-0.13%]
Total CPU difference: 5161.799999999972 / 5173.459999999983 [-0.23%]
Testing on Windows:
occt component :
Total MEMORY difference: 57230022 / 57236340 [-0.01%]
Total CPU difference: 19176.157723298707 / 18116.099728098634 [+5.85%]
products component :
Total MEMORY difference: 21274979 / 21238613 [+0.17%]
Total CPU difference: 5429.7240056999735 / 4976.229098699953 [+9.11%]
There are following differences in images found by testdiff.
http://occt-tests/CR27892_2-master-OCCT/Windows-64-VC10/diff-Windows-64-VC10-image.html
IMAGE bugs modalg_4 bug8842_8: bug8842_8.png differs
Branch CR27892_2 from occt git-repository (and master from products git-repository) was compiled on Linux, MacOS and Windows platforms and tested on Release mode.
[revision removed]
Number of compiler warnings:
occt component :
Linux: 0 (0 on master)
Windows: 0 (0 on master)
MacOS : 0 (0 on master)
products component :
Linux: 64 (64 on master)
Windows: 0 (0 on master)
MacOS : 1132
Regressions/Differences/Improvements:
No regressions/differences
Testing cases:
http://occt-tests/CR27892_2-master-OCCT/Debian70-64/offset/with_intersect_20/J9.html
http://occt-tests/CR27892_2-master-OCCT/Windows-64-VC10/offset/with_intersect_20/J9.html
offset with_intersect_20 J9: BAD (known problem)
http://occt-tests/CR27892_2-master-OCCT/Debian70-64/offset/with_intersect_80/J9.html
http://occt-tests/CR27892_2-master-OCCT/Windows-64-VC10/offset/with_intersect_80/J9.html
offset with_intersect_80 J9: BAD (known problem)
Testing on Linux:
occt component :
Total MEMORY difference: 90808033 / 90432455 [+0.42%]
Total CPU difference: 19343.93999999981 / 19274.589999999782 [+0.36%]
products component :
Total MEMORY difference: 29998286 / 30036359 [-0.13%]
Total CPU difference: 5161.799999999972 / 5173.459999999983 [-0.23%]
Testing on Windows:
occt component :
Total MEMORY difference: 57230022 / 57236340 [-0.01%]
Total CPU difference: 19176.157723298707 / 18116.099728098634 [+5.85%]
products component :
Total MEMORY difference: 21274979 / 21238613 [+0.17%]
Total CPU difference: 5429.7240056999735 / 4976.229098699953 [+9.11%]
There are following differences in images found by testdiff.
http://occt-tests/CR27892_2-master-OCCT/Windows-64-VC10/diff-Windows-64-VC10-image.html
IMAGE bugs modalg_4 bug8842_8: bug8842_8.png differs
Waiting resolution of #0027929
Dear Mikhail (MKV),
Now bug #0027929 is tested. The regression in "bugs modalg_4 bug8842_8" has been fixed.
Therefore, please reclassify this issue as TESTED, too.
TIA.
Now bug #0027929 is tested. The regression in "bugs modalg_4 bug8842_8" has been fixed.
Therefore, please reclassify this issue as TESTED, too.
TIA.
Branch [archived branch] has been deleted by Commenter 2.
[revision removed]
[revision removed]
Branch [archived branch] has been deleted by Commenter 2.
[revision removed]
[revision removed]
Branch [archived branch] has been deleted by Commenter 2.
[revision removed]
[revision removed]
Related records