MantisBT - Open CASCADE
View Issue Details
0025594Open CASCADE[OCCT] OCCT:Meshpublic2014-12-11 18:202018-12-03 10:38
[OCCT] 6.8.0 
[OCCT] 7.4.0* 
bugs mesh bug25594
0025594: Valid shape is not visualize in shading mode.
Attached valid face can not be visualized in shading mode.
Command "incmesh" on valid shape gives error "SelfIntersectonWire".
restore face1.brep b
Draw[11]> checkshape b f
 -- The Shape b looks OK
Draw[12]> incmesh b 0.001
Incremental Mesh, multi-threading OFF
Meshing statuses: SelfIntersectingWire
Draw[13]> vinit
Draw[14]> vdisplay b
Draw[15]> vfit
Draw[16]> setup Shaded display mode
No tags attached.
related to 0024084assigned oan Additional tool for resolving 2d loops on discretized wires should be implemented in BRepMesh 
related to 0025593closed bugmaster Number of intersection points for 2d curves depends on the order of arguments in command "2dintersect" 
? face1.brep (47,672) 2014-12-11 18:20
png wing_2d.png (14,565) 2014-12-12 11:15
png wing_3d.png (14,673) 2014-12-12 11:15
png indecisive_zone.png (4,626) 2016-04-04 13:46
Issue History
2014-12-11 18:20gkaNew Issue
2014-12-11 18:20gkaAssigned To => oan
2014-12-11 18:20gkaFile Added: face1.brep
2014-12-12 10:43oanRelationship addedrelated to 0024084
2014-12-12 11:03gkaSummaryValid shape is not vizualize in shading mode. => Valid shape is not visualize in shading mode.
2014-12-12 11:13oanNote Added: 0035349
2014-12-12 11:15oanFile Added: wing_2d.png
2014-12-12 11:15oanFile Added: wing_3d.png
2014-12-16 10:38msvRelationship addedrelated to 0025593
2014-12-16 10:41msvNote Added: 0035412
2014-12-16 10:41msvNote Edited: 0035412bug_revision_view_page.php?bugnote_id=35412#r8888
2014-12-16 11:13oanNote Added: 0035413
2014-12-16 11:16oanNote Edited: 0035413bug_revision_view_page.php?bugnote_id=35413#r8890
2015-04-21 06:09abvTarget Version6.9.0 => 7.1.0
2016-04-04 13:46oanFile Added: indecisive_zone.png
2016-04-04 13:57oanNote Added: 0052334
2016-04-04 13:57oanAssigned Tooan => msv
2016-04-04 13:57oanStatusnew => feedback
2016-04-05 13:54oanNote Added: 0052393
2016-04-05 13:55oanAssigned Tomsv => oan
2016-04-05 13:55oanStatusfeedback => assigned
2016-10-25 17:45oanTarget Version7.1.0 => 7.2.0
2017-07-20 12:43oanTarget Version7.2.0 => 7.3.0
2018-02-25 21:09abvTarget Version7.3.0 => 7.4.0*
2018-11-17 23:44oanNote Added: 0081139
2018-11-17 23:45oanNote Edited: 0081139bug_revision_view_page.php?bugnote_id=81139#r20393
2018-11-19 12:48gitNote Added: 0081164
2018-11-19 14:16oanNote Added: 0081165
2018-11-19 14:16oanAssigned Tooan => msv
2018-11-19 14:16oanStatusassigned => resolved
2018-11-30 11:55oanAssigned Tomsv => pdn
2018-11-30 17:24msvNote Added: 0081317
2018-11-30 17:24msvAssigned Topdn => bugmaster
2018-11-30 17:24msvStatusresolved => reviewed
2018-11-30 17:30apnTest case number => bugs mesh bug25594
2018-11-30 17:30apnNote Added: 0081318
2018-11-30 17:30apnStatusreviewed => tested
2018-12-02 14:48apnChangeset attached => occt master e2fc86bb
2018-12-02 14:48apnAssigned Tobugmaster => apn
2018-12-02 14:48apnStatustested => verified
2018-12-02 14:48apnResolutionopen => fixed
2018-12-03 10:38gitNote Added: 0081332

2014-12-12 11:13   
Shape is correct from point of view of "checkshape" functionality which takes into account vertex/edge/face tolerances to check correctness of shapes. Attached shape has tolerance ~0.025. Which is sufficiently large related to shape size. This tolerance covers self interseciton of outer wire (see attached screenshots).

Contrasting to checkshape, BRepMesh uses real geometry to produce discretization points as well as low level tools used there. Currently it does not contain tool to resolve self intersections and similar problems. Corresponding issue 0024084 was already been registered in Mantis.
2014-12-16 10:41   
As far as I understand the shape has self-intersection problem that is not recognized by checkshape. This problem is expected to be solved with the bug 0025593.
If checkshape reported the self-intersection problem the error in brep mesh algorithm would not be surprise.

2014-12-16 11:13   
(edited on: 2014-12-16 11:16)
I guess that checkshape works well, because it takes tolerance of the shape into account during checks and in this case size of the loop satisfies the value ~0.025.

If we try to change tolerance of first edge to 1e-2 we will get the following:

pload ALL
restore face1.brep a
checkshape a
# This shape seems to be valid

explode a e
settolerance a_1 1e-2
checkshape a
# On Shape faulty_1 :
# BRepCheck_SelfIntersectingWire
# On Shape faulty_2 :
# BRepCheck_UnorientableShape
# Shape faulty_1 on shape faulty_2 :
# BRepCheck_SelfIntersectingWire
# Faulty shapes in variables faulty_1 to faulty_2

However, it is possible that 0025593 will change behavior of checkshape and this case will become OK.

2016-04-04 13:57   
Dear Mikhail,

shape has indecisive zone problem (see attached screenshot) according to the shape validity criteria - tolerance of vertex does not cover this inconsistency. Like this, current shape is not valid and BRepMesh behavior is expected. Boosting vertex tolerance in couple with bunch of fixes #0027108 + 0027226 + 0027239 can give valid result for visualization. Thus I suggest to requalify this issue to OCCT:Shape Healing category in order to fit the validity criteria. Note that initially shape is translated from STEP file.
2016-04-05 13:54   
According to remarks given by MSV, shape can have different validity configurations thus it was mentioned that even if wire has self-intersection in 3d or 2d and it is covered by edge or vertex tolerance at least for one representation, this case is considered as valid. For the case of indecisive zone there is no strictly defined behavior how this case can be resolved: either by boosting of vertex tolerance (that can be the most suitable solution for meshers) or boosting of edge tolerance to cover the inconsistency. Like this, it is suggested by MSV to implement features local for BRepMesh already suggested in 0024084 for the sake of producing mesh suitable for visualization.
2018-11-17 23:44   
(edited on: 2018-11-17 23:45)
Shape can be correctly visualized on current master after fixshape (note that checkshape notifies no error despite of some corrections made by fixshape).

pload ALL
restore face1.brep a

vsetdispmode 1

checkshape a
# This shape seems to be valid

vdisplay a

trinfo a
# This shape contains 0 triangles.
# 0 nodes.
# Maximal deflection 0

fixshape a a
vdisplay a -redisplay

trinfo a
# This shape contains 374 triangles.
# 224 nodes.
# Maximal deflection 0.097668966673379987

Tolerance remains the same.

2018-11-19 12:48   
Branch CR25594 has been created by oan.

SHA-1: 28a0dfe59ba1feaa671f73b9a40ae52e2b860885

Detailed log of new commits:

Author: oan
Date: Mon Nov 19 12:41:55 2018 +0300

    0025594: Valid shape is not visualize in shading mode.
    Added test case.
2018-11-19 14:16   
Please review test case.

Test results:
http://occt-tests/CR25594-master-OAN-OCCT/Debian80-64/diff_summary.html [^]
http://occt-tests/CR25594-master-OAN-OCCT/Windows-64-VC14/diff_summary.html [^]
2018-11-30 17:24   
2018-11-30 17:30   
Test case:
bugs mesh bug25594 - OK
2018-12-03 10:38   
Branch CR25594 has been deleted by inv.

SHA-1: 28a0dfe59ba1feaa671f73b9a40ae52e2b860885