MantisBT - Community
View Issue Details
0031430Community[OCCT] OCCT:Modeling Datapublic2020-03-14 13:332020-03-22 11:44
Roman Lygin 
[OCCT] 7.5.0* 
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
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

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
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.
2020-03-16 11:31   
Branch CR31430 has been updated forcibly by msv.

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

SHA-1: a3b365ce2d39befb731c281844867996e659f5ea
2020-03-16 11:35   
Please review. [^]
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.
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.
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.
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.
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.
2020-03-18 09:52   
Branch CR31430 has been updated forcibly by msv.

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

SHA-1: 75a61baa9f129124e5556871d6cdd5c339dad689
2020-03-22 11:41   
Combination -
OCCT branch : IR-2020-03-20
master SHA - 7ef1f9b7c1d9301c158a593dc5facb5a33450318
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

No regressions/differences

CPU differences:
Total CPU difference: 16845.960000000137 / 16685.300000000094 [+0.96%]
Total CPU difference: 11305.960000000074 / 11298.700000000106 [+0.06%]
Total CPU difference: 18268.609375 / 18088.765625 [+0.99%]
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