MantisBT - Community
View Issue Details
0031430Community[OCCT] OCCT:Modeling Datapublic2020-03-14 13:332020-03-22 11:44
Roman Lygin 
bugmaster 
normalcrash 
verifiedfixed 
 
[OCCT] 7.5.0* 
bugs/modalg_7/bug31430
0031430: Modeling Data - Offset surfaces on C1 surfaces (with multiplicity equal to degree) may still throw exception
Valid offset surfaces created on C1-continuous basis surface (e.g. B-Spline) but with knot multiplicity equal to degree may cause an exception later on.
One of the scenarios is from inside Shape Healing, when Geom_RectangularTrimmedSurface on such offset will call a ctor of Geom_OffsetSurface with the parameter of enforced continuity check (which is a default value of the parameter). The check in G_OS ctor is based on knot multiplicity, not on real geometrical continuity.

Several approaches are possible:
a. enforce skipped continuity check in G_RTS ctor (as G_OS already existed by that time and thus is valid)
b. change checking algorithm to really verify C1/G1 continuity (not just knot multiplicity) and allow creation of OS. In this case the parameter can be removed at all.
c. change default value of parameter of continuity check in G_OS to skip the check and thus allow creation of offset on any surface.

I would recommend b or at least c, whereas a is just a bare minimum.
restore shape.brep s
fixshape r s
No tags attached.
related to 0025124closed bugmaster Community [Feature request] Removal of continuity checks for offset geometries 
related to 0031436new msv Open CASCADE Modeling Data - try to make the base surface C1 when creating offset surface 
7z shape.7z (8,894) 2020-03-14 13:33
https://tracker.dev.opencascade.org/
Issue History
2020-03-14 13:33Roman LyginNew Issue
2020-03-14 13:33Roman LyginAssigned To => msv
2020-03-14 13:33Roman LyginFile Added: shape.7z
2020-03-14 13:34Roman LyginRelationship addedrelated to 0025124
2020-03-14 13:35Roman LyginSummaryOffset surfaces on C1 surfaces => Offset surfaces on C1 surfaces (with multiplicity equal to degree) may still throw exception
2020-03-14 13:53gitNote Added: 0090942
2020-03-14 13:54Roman LyginNote Added: 0090943
2020-03-14 13:54Roman LyginStatusnew => resolved
2020-03-14 20:20kgvSummaryOffset surfaces on C1 surfaces (with multiplicity equal to degree) may still throw exception => Modeling Data - Offset surfaces on C1 surfaces (with multiplicity equal to degree) may still throw exception
2020-03-16 11:31gitNote Added: 0090955
2020-03-16 11:33gitNote Added: 0090956
2020-03-16 11:34msvAssigned Tomsv => abv
2020-03-16 11:35msvNote Added: 0090957
2020-03-16 12:30ifvNote Added: 0090961
2020-03-16 12:30ifvAssigned Toabv => msv
2020-03-16 12:30ifvStatusresolved => feedback
2020-03-16 12:52msvNote Added: 0090962
2020-03-16 12:52msvAssigned Tomsv => Roman Lygin
2020-03-16 13:23Roman LyginAssigned ToRoman Lygin => msv
2020-03-16 13:28Roman LyginNote Added: 0090965
2020-03-16 13:41ifvNote Added: 0090966
2020-03-16 13:46Roman LyginNote Added: 0090967
2020-03-18 09:52gitNote Added: 0091001
2020-03-18 09:53msvNote Added: 0091002
2020-03-18 09:56msvNote Added: 0091003
2020-03-18 09:56msvAssigned Tomsv => bugmaster
2020-03-18 09:56msvStatusfeedback => reviewed
2020-03-18 10:08msvRelationship addedrelated to 0031436
2020-03-18 11:10Roman LyginNote Added: 0091010
2020-03-19 16:31bugmasterChangeset attached => occt master fb991777
2020-03-19 16:31bugmasterStatusreviewed => verified
2020-03-19 16:31bugmasterResolutionopen => fixed
2020-03-22 11:31gitNote Added: 0091125
2020-03-22 11:41bugmasterNote Added: 0091159
2020-03-22 11:44bugmasterTest case number => bugs/modalg_7/bug31430

Notes
(0090942)
git   
2020-03-14 13:53   
Branch CR31430 has been created by Roman Lygin.

SHA-1: 69bc8943bdfffc43d78411a1d670195f209fe8a7


Detailed log of new commits:

Author: Roman Lygin
Date: Sat Mar 14 13:49:17 2020 +0300

    0031430: Offset surfaces on C1 surfaces (with multiplicity equal to degree) may still throw exception
(0090943)
Roman Lygin   
2020-03-14 13:54   
The simplest fix for the approach 'a' has been provided.
Options b and c remain at OCC team discretion.
(0090955)
git   
2020-03-16 11:31   
Branch CR31430 has been updated forcibly by msv.

SHA-1: 6055af5077808287fbca9e2052f24dde6aad5df1
(0090956)
git   
2020-03-16 11:33   
Branch CR31430 has been updated forcibly by msv.

SHA-1: a3b365ce2d39befb731c281844867996e659f5ea
(0090957)
msv   
2020-03-16 11:35   
Please review.
http://jenkins-test-12.nnov.opencascade.com/view/CR31430-master-MSV/view/COMPARE/ [^]
(0090961)
ifv   
2020-03-16 12:30   
It is not needed to integrate this fix because we have solution b. implemented yet.
The Roman's statement " The check in G_OS ctor is based on knot multiplicity, not on real geometrical continuity. " is wrong. Continuity check includes checking real geometry continuity.
(0090962)
msv   
2020-03-16 12:52   
Indeed, according to the actual code, the solution b) is implemented. The check is done with Precision::Angular(). May be the surface in the attached shape does not follow this condition, and the divergence of normals at knots exceeds the angular precision.

So, I am not sure if we can accept this patch with skipped check for C0.
(0090965)
Roman Lygin   
2020-03-16 13:28   
The original surface comes from Parasolid where angular precision is likely 1e-11 (not 1e-12 as in OCC).
Here is the workflow:
1. Create Geom_OffsetSurface on original basis surface (flag isnotC0Check = true).
2. Create face on this G_OS
3. Feed into Shape Healing.
4. Crash in FixMissingSeam which creates G_OS on top of G_RTS on top of original basis surface. When G_OS is created on G_RTS it uses isNotC0Check with default value which is false.

So the point is that OCC cannot create G_OS on top of the same basis surface it once considered acceptable for creating G_OS.
The fix is to stress the point - if the basis surface was once considered OK for G_OS then such a surface must remain valid inside OCC and must not be refused anywhere inside it.
(0090966)
ifv   
2020-03-16 13:41   
Roman, if offset surface is based on trimmed one, continuity check is performed for trimmed domain and surface can be valid. If we change trim, surface can become invalid.
(0090967)
Roman Lygin   
2020-03-16 13:46   
Igor, see the key point in explanation - if the surface is once valid for offset inside OCC it must remain valid inside it.
BTW, it's an opposite case here - the original B-Spline surface was once valid and then trimmed and then G_OS refused to accept it.
(0091001)
git   
2020-03-18 09:52   
Branch CR31430 has been updated forcibly by msv.

SHA-1: 75a61baa9f129124e5556871d6cdd5c339dad689
(0091002)
msv   
2020-03-18 09:53   
OK, we accept the fix with a) solution. I have updated the commit message with the reason.
(0091003)
msv   
2020-03-18 09:56   
For integration:
occt - CR31430
products - none.
(0091010)
Roman Lygin   
2020-03-18 11:10   
Thanks Mikhail!
(0091125)
git   
2020-03-22 11:31   
Branch CR31430 has been deleted by inv.

SHA-1: 75a61baa9f129124e5556871d6cdd5c339dad689
(0091159)
bugmaster   
2020-03-22 11:41   
Combination -
OCCT branch : IR-2020-03-20
master SHA - 7ef1f9b7c1d9301c158a593dc5facb5a33450318
fe4497f3246e6bc1ced97ac331c148f0809ded15
Products branch : IR-2020-03-20 SHA - f10b867b449ebfa55e0a3c8cb276ae511f9cf7f2
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: 16845.960000000137 / 16685.300000000094 [+0.96%]
Products
Total CPU difference: 11305.960000000074 / 11298.700000000106 [+0.06%]
Windows-64-VC14:
OCCT
Total CPU difference: 18268.609375 / 18088.765625 [+0.99%]
Products
Total CPU difference: 13110.078125 / 13084.390625 [+0.20%]


Image differences :
No differences that require special attention

Memory differences :
No differences that require special attention