MantisBT - Open CASCADE
View Issue Details
0028377Open CASCADE[OCCT] OCCT:Modeling Algorithmspublic2017-01-20 14:562018-06-29 21:19
nbv 
bugmaster 
normalminor 
closedfixed 
 
[OCCT] 7.3.0[OCCT] 7.3.0 
bugs modalg_7 bug28211_1
0028377: Valid face is classified as bad by BRepCheck algorithm
Two attached faces have the same topological structure (tolerance, number of entities and their orientation). They differ by width of the ring only (validface.brep has ring width 1.0+1.0e-5, problemface.brep has ring width 1.0e-5) - see attached picture "Valid and NOT valid faces.PNG".

However, one shape (validface.brep) is valid and another shape (problemface.brep) is not valid (BRepCheck_BadOrientationOfSubshape).

Indeed, two faces seems to be valid.
restore validface.brep f1
checkshape f1
#This shape seems to be valid

restore problemface.brep f2
checkshape f2
#BRepCheck_BadOrientationOfSubshape

fixshape r f2
# Face has been turned inside out, even in case f2 is classified as valid
No tags attached.
? problemface.brep (2,240) 2017-01-20 14:56
https://tracker.dev.opencascade.org/
? validface.brep (2,238) 2017-01-20 14:57
https://tracker.dev.opencascade.org/
png Valid and NOT valid faces.PNG (16,541) 2017-01-20 16:55
https://tracker.dev.opencascade.org/
Issue History
2017-01-20 14:56nbvNew Issue
2017-01-20 14:56nbvAssigned To => msv
2017-01-20 14:56nbvFile Added: problemface.brep
2017-01-20 14:57nbvFile Added: validface.brep
2017-01-20 15:00nbvNote Added: 0062837
2017-01-20 15:19msvRelationship addedrelated to 0028211
2017-01-20 16:35nbvNote Edited: 0062837bug_revision_view_page.php?bugnote_id=62837#r15884
2017-01-20 16:39nbvDescription Updatedbug_revision_view_page.php?rev_id=15886#r15886
2017-01-20 16:50nbvNote Added: 0062850
2017-01-20 16:55nbvFile Added: Valid and NOT valid faces.PNG
2017-01-20 16:55nbvDescription Updatedbug_revision_view_page.php?rev_id=15887#r15887
2017-01-20 17:00nbvNote Added: 0062851
2017-01-20 17:00nbvNote Edited: 0062851bug_revision_view_page.php?bugnote_id=62851#r15889
2017-01-30 12:13msvAssigned Tomsv => ifv
2017-01-30 12:13msvStatusnew => assigned
2017-01-30 12:14msvNote Added: 0063184
2017-02-01 09:45nbvNote Added: 0063278
2017-02-01 12:05azvNote Added: 0063282
2017-02-01 12:05azvSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=15985#r15985
2017-02-01 13:12nbvNote Edited: 0063278bug_revision_view_page.php?bugnote_id=63278#r15989
2017-03-07 13:35nbvNote Added: 0064170
2017-03-07 15:51msvAssigned Toifv => nbv
2017-03-07 16:02nbvRelationship addedrelated to 0028523
2017-07-24 09:22msvTarget Version7.2.0 => 7.3.0
2017-10-17 18:14nbvNote Added: 0071583
2017-10-17 18:14nbvStatusassigned => feedback
2018-01-16 09:35nbvNote Added: 0073426
2018-01-16 09:35nbvAssigned Tonbv => bugmaster
2018-01-16 10:19apnTest case number => bugs modalg_7 bug28211_1
2018-01-16 10:19apnNote Added: 0073427
2018-01-16 10:19apnStatusfeedback => verified
2018-01-16 10:19apnResolutionopen => fixed
2018-06-29 21:15aivFixed in Version => 7.3.0
2018-06-29 21:19aivStatusverified => closed

Notes
(0062837)
nbv   
2017-01-20 15:00   
(edited on: 2017-01-20 16:35)
After the fix for issue #0028211, these shapes can be obtained with the following scripts:

VALIDFACE:

Draw[2]> circle c1 0 0 0 14.00005
Draw[3]> trim c1 c1 pi 2*pi
Draw[4]> line c2 0 0 0 1 0 0
Draw[5]> trim c2 c2 -14.00005 14.00005
Draw[6]> mkedge e1 c1
Draw[7]> mkedge e2 c2
Draw[8]>
Draw[9]> plane s1 0 0 0 0 0 1
Draw[10]> wire ww e1 e2
Draw[11]> mkface ff s1 ww
Draw[12]>
Draw[13]> circle cn 0 0 0 13
Draw[14]> trim cn1 cn 2.37659982087888 3.9065854863007
Draw[15]> trim cn2 cn 3.9065854863007 3.94739614767378
Draw[16]> trim cn3 cn 3.94739614767378 5.4773818130956
Draw[17]> trim cn4 cn 5.4773818130956 5.51819247446868
Draw[18]> trim cn5 cn 5.51819247446868 6.2831853071795862
Draw[19]>
Draw[20]> mkedge e1 cn1
Draw[21]> mkedge e2 cn2
Draw[22]> mkedge e3 cn3
Draw[23]> mkedge e4 cn4
Draw[24]> mkedge e5 cn5
Draw[25]>
Draw[26]> bclearobjects
Draw[27]> bcleartools
Draw[28]> baddobjects ff
Draw[29]> baddtools e1 e2 e3 e4 e5
Draw[30]> bfillds
Draw[31]> bbuild ff


PROBLEMFACE:

The same but set in "Draw[13]" circle radius 14.

(0062850)
nbv   
2017-01-20 16:50   
At present (while issue #28211 is not fixed), PROBLEMFACE in above script cannot be built. After the fix #28211, this face can be built but will be classified as invalid in spite of its valid.

This problem must be solved in this issue.
(0062851)
nbv   
2017-01-20 17:00   
Script below creates the face which is analogical to PROBLEMFACE with help of standard DRAW-commands (not Boolean operation). Result face is valid, hovewer, has another orientation (i.e. hole, indeed).

circle c1 0 0 0 14.00005
line c2 0 0 0 1 0 0
circle cn 0 0 0 14

trim c1 c1 3.1415926535897931 6.2831853071795862
trim c00 c2 -14.00005 -14.0000
trim c01 c2  14.00000  14.00005
trim cn1 cn 3.1415926535897931 3.9065854863007
trim cn2 cn 3.9065854863007 3.94739614767378
trim cn3 cn 3.94739614767378 5.4773818130956
trim cn4 cn 5.4773818130956 5.51819247446868
trim cn5 cn 5.51819247446868 6.2831853071795862

mkedge e1 c1
mkedge e2 c01
mkedge e3 cn5
mkedge e4 cn4
mkedge e5 cn3
mkedge e6 cn2
mkedge e7 cn1
mkedge e8 c00

orientation e1 F
orientation e2 R
orientation e3 R
orientation e4 R
orientation e5 R
orientation e6 R
orientation e7 R
orientation e8 R
wire ww e1 e2 e3 e4 e5 e6 e7 e8
plane s1 0 0 0 0 0 1
mkface fv s1 ww

checkshape fv

axo 
don fv
fit


(0063184)
msv   
2017-01-30 12:14   
Please estimate it as addition to #28211.
(0063278)
nbv   
2017-02-01 09:45   
(edited on: 2017-02-01 13:12)
This bug is result of wrong work of BRepTopAdaptor_FClass2d classifier used in BRepCheck algorithms. It classifies this face as hole by mistake (the same problem as in IntTools_FClass2d classifier in the issue #28211).

After draft unification IntTools_FClass2d and BRepTopAdaptor_FClass2d algorithm of IntTools_FClass2d has been moved completely in BRepTopAdaptor_FClass2d and IntTools_FClass2d has been eliminated from OCCT and replaced with BRepTopAdaptor_FClass2d), I have obtained 111 regressions on my local machine (in OCCT only, without OCCT-products). These regressions are needed in additional analysis.

Described problem with checkshape has been fixed by this way.

(0063282)
azv   
2017-02-01 12:05   
Note, that fixshape turns problemface.brep inside out anyway. In case of the face is classified as wrong, it makes valid face with material outside. But if the face is valid, it makes wrong face according to checkshape's output.
(0064170)
nbv   
2017-03-07 13:35   
ShapeFix_Face::FixOrientation(...) method reverses the face which has no outer bound(s) (ShapeAnalysis::IsOuterBound(...)). This method seems to work worse. It is the reason why the face changes its orientation in fixshape algorithm.
(0071583)
nbv   
2017-10-17 18:14   
This problem should be solved in frame of the issue #28211.
(0073426)
nbv   
2018-01-16 09:35   
Dear Bugmaster.

This issue is not reproduced on the current MASTER. See "bugs modalg_7 bug28211_1" test case.

Please close it.
(0073427)
apn   
2018-01-16 10:19   
Fixed in #28211.