MantisBT - Open CASCADE
View Issue Details
0030497Open CASCADE[OCCT] OCCT:Meshpublic2019-02-15 09:302019-03-05 13:47
nds 
apn 
normalmajor 
closedfixed 
[OCCT] 7.4.0 
[OCCT] 7.4.0[OCCT] 7.4.0 
bugs moddata_3 bug30497
0030497: [REGRESSION] Mesh - wrong Poly_Polygon3D within local selection of located shape
Highlight and selection on a shape with its own location (not default) is in wrong position.
pload XDE VISUALIZATION
testreadstep as1-oc-214-mat.stp s
#restore s730_OK.brep s
#restore s740dev_KO.brep s
vclear
vinit View1
vaxo
vdisplay s -dispmode 1
vfit
vselmode 2 1
vmoveto 150 201
No tags attached.
parent of 0030528new oan Reduced data model with edges with an unique TEdges 
related to 0030511closed apn Mesh - too long meshing of assembly containing single solid (shared) 
child of 0026106closed bugmaster BRepMesh - revision of data model 
Not all the children of this issue are yet resolved or closed.
png located_shape_wrong_position.png (10,796) 2019-02-15 09:30
https://tracker.dev.opencascade.org/
? as1-oc-214-mat.stp (445,345) 2019-02-15 09:37
https://tracker.dev.opencascade.org/
? s730_OK.brep (401,373) 2019-02-15 12:29
https://tracker.dev.opencascade.org/
? s740dev_KO.brep (438,035) 2019-02-15 12:29
https://tracker.dev.opencascade.org/
Issue History
2019-02-15 09:30ndsNew Issue
2019-02-15 09:30ndsAssigned To => kgv
2019-02-15 09:30ndsFile Added: located_shape_wrong_position.png
2019-02-15 09:32ndsRelationship addedrelated to 0026106
2019-02-15 09:36ndsNote Added: 0082190
2019-02-15 09:37ndsFile Added: as1-oc-214-mat.stp
2019-02-15 09:38ndsNote Edited: 0082190bug_revision_view_page.php?bugnote_id=82190#r20672
2019-02-15 12:28kgvSeverityminor => major
2019-02-15 12:28kgvCategoryOCCT:Visualization => OCCT:Mesh
2019-02-15 12:28kgvProduct Version => 7.4.0
2019-02-15 12:28kgvSummaryVisualization - regression - wrong local selection of located shape => [REGRESSION] Mesh - wrong local selection of located shape
2019-02-15 12:29kgvFile Added: s730_OK.brep
2019-02-15 12:29kgvFile Added: s740dev_KO.brep
2019-02-15 12:29kgvSummary[REGRESSION] Mesh - wrong local selection of located shape => [REGRESSION] Mesh - wrong Poly_Polygon3D within local selection of located shape
2019-02-15 12:31kgvNote Added: 0082193
2019-02-15 12:31kgvAssigned Tokgv => oan
2019-02-15 12:33kgvSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=20675#r20675
2019-02-15 13:08kgvRelationship replacedchild of 0026106
2019-02-15 16:22oanNote Added: 0082198
2019-02-15 16:22oanNote Edited: 0082198bug_revision_view_page.php?bugnote_id=82198#r20679
2019-02-15 16:23oanNote Edited: 0082198bug_revision_view_page.php?bugnote_id=82198#r20680
2019-02-15 16:25oanNote Edited: 0082198bug_revision_view_page.php?bugnote_id=82198#r20681
2019-02-19 14:03gitNote Added: 0082222
2019-02-20 16:18gitNote Added: 0082239
2019-02-20 16:19ndsAssigned Tooan => nds
2019-02-21 11:11gitNote Added: 0082269
2019-02-21 11:19ndsNote Added: 0082270
2019-02-21 11:19ndsAssigned Tonds => msv
2019-02-21 16:54msvStatusnew => resolved
2019-02-21 17:02msvNote Added: 0082277
2019-02-21 17:02msvAssigned Tomsv => nds
2019-02-21 17:02msvStatusresolved => assigned
2019-02-21 18:02gitNote Added: 0082281
2019-02-21 19:03oanNote Added: 0082285
2019-02-21 19:24oanNote Edited: 0082285bug_revision_view_page.php?bugnote_id=82285#r20700
2019-02-21 19:25oanNote Edited: 0082285bug_revision_view_page.php?bugnote_id=82285#r20701
2019-02-22 07:12gitNote Added: 0082286
2019-02-22 09:13gitNote Added: 0082287
2019-02-22 13:55ndsNote Added: 0082301
2019-02-22 13:55ndsAssigned Tonds => msv
2019-02-22 16:47msvNote Added: 0082307
2019-02-22 16:48msvStatusassigned => resolved
2019-02-22 16:48msvNote Added: 0082308
2019-02-22 16:48msvAssigned Tomsv => bugmaster
2019-02-22 16:48msvStatusresolved => reviewed
2019-02-22 16:48msvAssigned Tobugmaster => nds
2019-02-22 16:48msvStatusreviewed => assigned
2019-02-22 16:52msvNote Added: 0082310
2019-02-22 16:53msvNote Edited: 0082310bug_revision_view_page.php?bugnote_id=82310#r20707
2019-02-22 17:14msvAssigned Tonds => oan
2019-02-22 17:14msvNote Added: 0082311
2019-02-22 19:07gitNote Added: 0082313
2019-02-25 11:35gitNote Added: 0082325
2019-02-25 11:53gitNote Added: 0082326
2019-02-25 13:47oanNote Added: 0082331
2019-02-25 13:47oanAssigned Tooan => msv
2019-02-25 13:47oanStatusassigned => resolved
2019-02-25 13:48oanRelationship addedrelated to 0030511
2019-02-27 16:56msvNote Added: 0082422
2019-02-27 16:56msvAssigned Tomsv => oan
2019-02-27 16:56msvStatusresolved => assigned
2019-02-28 10:01gitNote Added: 0082438
2019-02-28 10:06oanRelationship addedparent of 0030528
2019-02-28 10:07oanNote Added: 0082440
2019-02-28 10:07oanAssigned Tooan => msv
2019-02-28 10:07oanStatusassigned => resolved
2019-02-28 10:58gitNote Added: 0082444
2019-02-28 11:03gitNote Added: 0082445
2019-02-28 15:03msvNote Added: 0082456
2019-02-28 15:03msvAssigned Tomsv => bugmaster
2019-02-28 15:03msvStatusresolved => reviewed
2019-02-28 16:05apnTest case number => bugs moddata_3 bug30497
2019-02-28 18:35apnNote Added: 0082469
2019-02-28 18:35apnStatusreviewed => tested
2019-03-03 21:12apnChangeset attached => occt master 967d2f4f
2019-03-03 21:12apnAssigned Tobugmaster => apn
2019-03-03 21:12apnStatustested => verified
2019-03-03 21:12apnResolutionopen => fixed
2019-03-05 13:46gitNote Added: 0082645
2019-03-05 13:46gitNote Added: 0082646
2019-03-05 13:46gitNote Added: 0082647
2019-03-05 13:47gitNote Added: 0082648

Notes
(0082190)
nds   
2019-02-15 09:36   
(edited on: 2019-02-15 09:38)
This DRAW scenario starts reproducing with the fix for 0026106 (7bd071edb13e5aa7a1d3aed4ed4366fe3da83324).
On the previous commit it works correct (80da8585f4351470d5034519a8468a88bd12a819).

(0082193)
kgv   
2019-02-15 12:31   
It seems that mesh generated after 0026106 contains wrong Poly_Polygon3D data - see attached s730_OK.brep and s740dev_KO.brep files exported from OCCT 7.3.0 and from current master.
(0082198)
oan   
2019-02-15 16:22   
(edited on: 2019-02-15 16:25)
Model looks so it should not contain Poly_Polygon3D as far as there are no obvious free edges.

However, currently, implementation considers edges as logically free if they do not have any discrete pcurves, i.e. when edge is registered in the model, but no face uses it and its orientation is not EXTERNAL. Here, it should be edge, e.g. No19.

The possible solution is leave such edges without processing at all.

Another question is why selection does not take location of shape into account in order to transform polygon stored in TopoDS_Edge properly.

Good use case to be added to tests data base, thanks.

(0082222)
git   
2019-02-19 14:03   
Branch CR30497 has been created by nds.

SHA-1: ef39d5f7b91a115ac0ec69f86fa1ba73e2395244


Detailed log of new commits:

Author: nds
Date: Tue Feb 19 13:58:30 2019 +0300

    0030497: [REGRESSION] Mesh - wrong Poly_Polygon3D within local selection of located shape
(0082239)
git   
2019-02-20 16:18   
Branch CR30497_1 has been created by nds.

SHA-1: 9e00d610b88e4f1778a5a55fe9c50d2665169d28


Detailed log of new commits:

Author: nds
Date: Wed Feb 20 16:14:03 2019 +0300

    0030497: [REGRESSION] Mesh - wrong Poly_Polygon3D within local selection of located shape
    
    The previous code has a condition to avoid processing the same faces if the face has a location.
    The similar condition should be applied during the edges processing.
    If not doing this, in the previous imlementation, IMeshData_Edge instances are created for all edges(even located), but edges of faces located are not filled with curves.
    As a result we had wrong local selection of edges.
(0082269)
git   
2019-02-21 11:11   
Branch CR30497_1 has been updated by nds.

SHA-1: b03a6ec5ae5d7e9d157aa1dae966960c6671123b


Detailed log of new commits:

Author: nds
Date: Thu Feb 21 11:06:54 2019 +0300

    0030497: [REGRESSION] Mesh - wrong Poly_Polygon3D within local selection of located shape
    
    # test information correction

(0082270)
nds   
2019-02-21 11:19   
Dear Mikhail,
could you please review modifications.

Job on Jenkins is http://vm-jenkins-test-12.nnov.opencascade.com:8080/view/CR30497-master-NDS/. [^]
(0082277)
msv   
2019-02-21 17:02   
tests/bugs/moddata_3/bug30497
- change the command of file loading:
testreadstep locate_data_file as1-oc-214-mat.stp] s

Change the script of the failed test to increase delta of wsetpeek.

Please re-test.
(0082281)
git   
2019-02-21 18:02   
Branch CR30497_1 has been updated by nds.

SHA-1: dfc0e690b3dfb3ab6e1c67ee5ce748c02f1f4949


Detailed log of new commits:

Author: nds
Date: Thu Feb 21 17:57:58 2019 +0300

    0030497: [REGRESSION] Mesh - wrong Poly_Polygon3D within local selection of located shape
    
    # tests correction

(0082285)
oan   
2019-02-21 19:03   
(edited on: 2019-02-21 19:25)
DC,

I disagree with implemented solution as far as it suggests to iterate over list of faces twice, first to identify edges forming faces, second to register faces.

So as far as it is not a common problem, but inconsistency face on a single model, it could lead to possible performance slowdown on models consisting of enormous number of faces/edges (please take into account issue 0030511).

Here we have edges that is not external (free), but not involed into any face, so some of edges contain no discrete pcurves.

Like this, it would be better to add some status for such edges (with no pcurves, but not internal):
1) for performance reasons;
2) to notify user about inconsistency in the model (0026106:0080463);
3) to have an info about inconsistencies in the model for debug needs as far as it would be hard to detect such cases if we apply current patch.

Possible solution:
1) introduce new status IMeshData_OrphanEdge to IMeshData_Status;
2) set IMeshData_OrphanEdge in BRepMesh_ModelPreProcessor::Perform during check of edges of model for edges with no discrete pcurves which status is not TopAbs_External;
3) Prevent discretization of Orphan edges in BRepMesh_EdgeDiscret::process;
4) Prevent processing of Orphan edges in BRepMesh_ModelPostProcessor.cxx, PolygonCommitter.

(0082286)
git   
2019-02-22 07:12   
Branch CR30497_2 has been created by nds.

SHA-1: fc5c1cc8e7392526179872156243ee3f5cf4e635


Detailed log of new commits:

Author: nds
Date: Fri Feb 22 07:07:53 2019 +0300

    0030497: [REGRESSION] Mesh - wrong Poly_Polygon3D within local selection of located shape
    
    The previous code has a condition to avoid processing the same faces if the face has a location.
    The similar condition should be applied during the edges processing.
    If not doing this, in the previous implementation, IMeshData_Edge instances are created for all edges(even located), but edges of faces located are not filled with curves.
    As a result we had wrong local selection of edges.
(0082287)
git   
2019-02-22 09:13   
Branch CR30497_2 has been updated by nds.

SHA-1: d5fb9d69db26c95ea9da4dd6491ca52dd1433f64


Detailed log of new commits:

Author: nds
Date: Fri Feb 22 09:08:34 2019 +0300

    0030497: [REGRESSION] Mesh - wrong Poly_Polygon3D within local selection of located shape
    
    # test correction

(0082301)
nds   
2019-02-22 13:55   
Dear Mikhail,

the remarks are corrected, placed on CR30497_2. Please, check.
Jenkins job is the same:
http://vm-jenkins-test-12.nnov.opencascade.com:8080/view/CR30497-master-NDS/ [^]
(0082307)
msv   
2019-02-22 16:47   
Oleg, you did not understand the root of the problem. The fix is correct.
(0082308)
msv   
2019-02-22 16:48   
Reviewed.
(0082310)
msv   
2019-02-22 16:52   
(edited on: 2019-02-22 16:53)
Stop, I just now realized, that with this fix the connected edges will be visited several times, as they are visited with each face containing them. It is needed to restrict repeated visiting using a map.

Also, it is possible to avoid iterating the list of faces twice (complaint of Oleg), visiting in the same loop first the edges of the face, and then the face itself.

(0082311)
msv   
2019-02-22 17:14   
Dear Oleg, could you complete the fix?
(0082313)
git   
2019-02-22 19:07   
Branch CR30497_3 has been created by oan.

SHA-1: b8024f2441dc7ef3b8ed839e6382ebf3e5fc8423


Detailed log of new commits:

Author: oan
Date: Fri Feb 22 19:02:21 2019 +0300

    0030497: [REGRESSION] Mesh - wrong Poly_Polygon3D within local selection of located ShapeExtend_WireData
    
    Explode shape on edges and faces with unique TEdges and TFaces.
(0082325)
git   
2019-02-25 11:35   
Branch CR30497_2 has been updated by oan.

SHA-1: 1e8baa1bca4b75ef4f2129f0cc44271d4cc41243


Detailed log of new commits:

Author: oan
Date: Mon Feb 25 11:30:10 2019 +0300

    0030497: [REGRESSION] Mesh - wrong Poly_Polygon3D within local selection of located ShapeExtend_WireData
    
    Limit addition of edges to data model by ones with unique TShape and location using edges map already available in BRepMesh_ShapeVisitor;
    IMeshTools_ShapeExplorer: remove redundant iteration over faces; remove code duplication related to iteration over edges of shape.

(0082326)
git   
2019-02-25 11:53   
Branch CR30497_2 has been updated forcibly by oan.

SHA-1: a6a38928adcbdfdbd0bc92978f41cc1875da6593
(0082331)
oan   
2019-02-25 13:47   
DC,

I have tried to prototype another approach, consisting of extraction of edges with unique TEdges. Such approach can potentially reduce amount of memory needed to keep shared shapes and time needed for their meshing.

First results are available by the link below (note that there are several cases where it gives benefit about 80% for memory utilization):
http://occt-tests/CR30497_3-master-OAN-OCCT/Debian80-64/diff_summary.html [^]

However, such approach is much more complex than currenly proposed solution and requires additional modifications to store locations of edges forming shape's faces directly in data model as well as modifications of tessellation tools for correct processing of such cases.

Both approaches significantly improve performance of 0030511 issue.

Like this, for now for the sake of stability before the release I suggest:

1) to integrate modified version of patch provided by Natalia and available in updated CR30497_2 branch;
2) consider possibility of implementation of reduced data model that takes into account only edges with an unique TEdges without relation to their locations.

Test reports for updated CR30497_2 patch are available here:
http://occt-tests/master-CR30497_2-OAN-OCCT/Windows-64-VC14/diff_summary.html [^]
http://occt-tests/master-CR30497_2-OAN-OCCT/Debian80-64/diff_summary.html [^]


Please review.
(0082422)
msv   
2019-02-27 16:56   
Oleg, I agree with this plan. You can create a new issue for the item 2.
For the item 1, I have reviewed without remarks. Just please combine the branch in one commit with a proper commit message.
(0082438)
git   
2019-02-28 10:01   
Branch CR30497_2 has been updated forcibly by oan.

SHA-1: 73443a06be92dcf7f974647ea2096f7b84774154
(0082440)
oan   
2019-02-28 10:07   
Done.
(0082444)
git   
2019-02-28 10:58   
Branch CR30497_2 has been updated forcibly by oan.

SHA-1: 53298de03e88a2f30e4f9f73a872f47a36d88c83
(0082445)
git   
2019-02-28 11:03   
Branch CR30497_2 has been updated forcibly by oan.

SHA-1: 643073552db0bfdde903a577bcd00f0658c123e3
(0082456)
msv   
2019-02-28 15:03   
Reviewed.
(0082469)
apn   
2019-02-28 18:35   
Combination -
OCCT branch : CR30497_2
master SHA - 643073552db0bfdde903a577bcd00f0658c123e3
d67d4b811012eef8913d3c535c29654d0acf3c4c
Products branch : master SHA - b4f0b00c20dec5376d841941164e1fa4249d1d84
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: 16520.669999999955 / 16542.15999999996 [-0.13%]
Products
Total CPU difference: 9066.360000000039 / 9061.510000000035 [+0.05%]
Windows-64-VC14:
OCCT
Total CPU difference: 17961.21875 / 17946.09375 [+0.08%]
Products
Total CPU difference: 10481.953125 / 10439.25 [+0.41%]

Image differences :
No differences that require special attention

Memory differences :
No differences that require special attention
(0082645)
git   
2019-03-05 13:46   
Branch CR30497 has been deleted by kgv.

SHA-1: ef39d5f7b91a115ac0ec69f86fa1ba73e2395244
(0082646)
git   
2019-03-05 13:46   
Branch CR30497_1 has been deleted by kgv.

SHA-1: dfc0e690b3dfb3ab6e1c67ee5ce748c02f1f4949
(0082647)
git   
2019-03-05 13:46   
Branch CR30497_2 has been deleted by kgv.

SHA-1: 643073552db0bfdde903a577bcd00f0658c123e3
(0082648)
git   
2019-03-05 13:47   
Branch CR30497_3 has been deleted by kgv.

SHA-1: b8024f2441dc7ef3b8ed839e6382ebf3e5fc8423