MantisBT
Mantis Bug Tracker Workflow

View Issue Details Jump to Notes ] Related Changesets ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0030497Open CASCADE[OCCT] OCCT:Meshpublic2019-02-15 09:302019-03-05 13:47
Reporternds 
Assigned Toapn 
PrioritynormalSeveritymajor 
StatusverifiedResolutionfixed 
PlatformOSOS Version
Product Version[OCCT] 7.4.0* 
Target Version[OCCT] 7.4.0*Fixed in Version 
Summary0030497: [REGRESSION] Mesh - wrong Poly_Polygon3D within local selection of located shape
DescriptionHighlight and selection on a shape with its own location (not default) is in wrong position.
Steps To Reproduce
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
TagsNo tags attached.
Test case numberbugs moddata_3 bug30497
Attached Filespng file icon located_shape_wrong_position.png (10,796 bytes) 2019-02-15 09:30
? file icon as1-oc-214-mat.stp (445,345 bytes) 2019-02-15 09:37
? file icon s730_OK.brep (401,373 bytes) 2019-02-15 12:29
? file icon s740dev_KO.brep (438,035 bytes) 2019-02-15 12:29

- Relationships
parent of 0030528newoan Reduced data model with edges with an unique TEdges 
related to 0030511verifiedapn Mesh - too long meshing of assembly containing single solid (shared) 
child of 0026106verifiedbugmaster BRepMesh - revision of data model 
Not all the children of this issue are yet resolved or closed.

-  Notes
(0082190)
nds (developer)
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 (developer)
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 (developer)
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 (administrator)
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 (administrator)
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 (administrator)
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 (developer)
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 (developer)
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 (administrator)
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 (developer)
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 (administrator)
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 (administrator)
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 (developer)
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 (developer)
2019-02-22 16:47

Oleg, you did not understand the root of the problem. The fix is correct.
(0082308)
msv (developer)
2019-02-22 16:48

Reviewed.
(0082310)
msv (developer)
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 (developer)
2019-02-22 17:14

Dear Oleg, could you complete the fix?
(0082313)
git (administrator)
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 (administrator)
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 (administrator)
2019-02-25 11:53

Branch CR30497_2 has been updated forcibly by oan.

SHA-1: a6a38928adcbdfdbd0bc92978f41cc1875da6593
(0082331)
oan (developer)
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 (developer)
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 (administrator)
2019-02-28 10:01

Branch CR30497_2 has been updated forcibly by oan.

SHA-1: 73443a06be92dcf7f974647ea2096f7b84774154
(0082440)
oan (developer)
2019-02-28 10:07

Done.
(0082444)
git (administrator)
2019-02-28 10:58

Branch CR30497_2 has been updated forcibly by oan.

SHA-1: 53298de03e88a2f30e4f9f73a872f47a36d88c83
(0082445)
git (administrator)
2019-02-28 11:03

Branch CR30497_2 has been updated forcibly by oan.

SHA-1: 643073552db0bfdde903a577bcd00f0658c123e3
(0082456)
msv (developer)
2019-02-28 15:03

Reviewed.
(0082469)
apn (administrator)
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 (administrator)
2019-03-05 13:46

Branch CR30497 has been deleted by kgv.

SHA-1: ef39d5f7b91a115ac0ec69f86fa1ba73e2395244
(0082646)
git (administrator)
2019-03-05 13:46

Branch CR30497_1 has been deleted by kgv.

SHA-1: dfc0e690b3dfb3ab6e1c67ee5ce748c02f1f4949
(0082647)
git (administrator)
2019-03-05 13:46

Branch CR30497_2 has been deleted by kgv.

SHA-1: 643073552db0bfdde903a577bcd00f0658c123e3
(0082648)
git (administrator)
2019-03-05 13:47

Branch CR30497_3 has been deleted by kgv.

SHA-1: b8024f2441dc7ef3b8ed839e6382ebf3e5fc8423

- Related Changesets
occt: master 967d2f4f
Timestamp: 2019-02-28 06:55:53
Author: nds
Committer: apn
Details ] Diff ]
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.

Limit addition of edges to data model by ones with unique TShape and location using edges map already available in BRepMesh_ShapeVisitor.
mod - src/BRepMesh/BRepMesh_ShapeVisitor.cxx Diff ] File ]
mod - src/IMeshTools/IMeshTools_ShapeExplorer.cxx Diff ] File ]
mod - tests/bugs/mesh/bug25364 Diff ] File ]
add - tests/bugs/moddata_3/bug30497 Diff ] File ]

- Issue History
Date Modified Username Field Change
2019-02-15 09:30 nds New Issue
2019-02-15 09:30 nds Assigned To => kgv
2019-02-15 09:30 nds File Added: located_shape_wrong_position.png
2019-02-15 09:32 nds Relationship added related to 0026106
2019-02-15 09:36 nds Note Added: 0082190
2019-02-15 09:37 nds File Added: as1-oc-214-mat.stp
2019-02-15 09:38 nds Note Edited: 0082190 View Revisions
2019-02-15 12:28 kgv Severity minor => major
2019-02-15 12:28 kgv Category OCCT:Visualization => OCCT:Mesh
2019-02-15 12:28 kgv Product Version => 7.4.0*
2019-02-15 12:28 kgv Summary Visualization - regression - wrong local selection of located shape => [REGRESSION] Mesh - wrong local selection of located shape
2019-02-15 12:29 kgv File Added: s730_OK.brep
2019-02-15 12:29 kgv File Added: s740dev_KO.brep
2019-02-15 12:29 kgv Summary [REGRESSION] Mesh - wrong local selection of located shape => [REGRESSION] Mesh - wrong Poly_Polygon3D within local selection of located shape
2019-02-15 12:31 kgv Note Added: 0082193
2019-02-15 12:31 kgv Assigned To kgv => oan
2019-02-15 12:33 kgv Steps to Reproduce Updated View Revisions
2019-02-15 13:08 kgv Relationship replaced child of 0026106
2019-02-15 16:22 oan Note Added: 0082198
2019-02-15 16:22 oan Note Edited: 0082198 View Revisions
2019-02-15 16:23 oan Note Edited: 0082198 View Revisions
2019-02-15 16:25 oan Note Edited: 0082198 View Revisions
2019-02-19 14:03 git Note Added: 0082222
2019-02-20 16:18 git Note Added: 0082239
2019-02-20 16:19 nds Assigned To oan => nds
2019-02-21 11:11 git Note Added: 0082269
2019-02-21 11:19 nds Note Added: 0082270
2019-02-21 11:19 nds Assigned To nds => msv
2019-02-21 16:54 msv Status new => resolved
2019-02-21 17:02 msv Note Added: 0082277
2019-02-21 17:02 msv Assigned To msv => nds
2019-02-21 17:02 msv Status resolved => assigned
2019-02-21 18:02 git Note Added: 0082281
2019-02-21 19:03 oan Note Added: 0082285
2019-02-21 19:24 oan Note Edited: 0082285 View Revisions
2019-02-21 19:25 oan Note Edited: 0082285 View Revisions
2019-02-22 07:12 git Note Added: 0082286
2019-02-22 09:13 git Note Added: 0082287
2019-02-22 13:55 nds Note Added: 0082301
2019-02-22 13:55 nds Assigned To nds => msv
2019-02-22 16:47 msv Note Added: 0082307
2019-02-22 16:48 msv Status assigned => resolved
2019-02-22 16:48 msv Note Added: 0082308
2019-02-22 16:48 msv Assigned To msv => bugmaster
2019-02-22 16:48 msv Status resolved => reviewed
2019-02-22 16:48 msv Assigned To bugmaster => nds
2019-02-22 16:48 msv Status reviewed => assigned
2019-02-22 16:52 msv Note Added: 0082310
2019-02-22 16:53 msv Note Edited: 0082310 View Revisions
2019-02-22 17:14 msv Assigned To nds => oan
2019-02-22 17:14 msv Note Added: 0082311
2019-02-22 19:07 git Note Added: 0082313
2019-02-25 11:35 git Note Added: 0082325
2019-02-25 11:53 git Note Added: 0082326
2019-02-25 13:47 oan Note Added: 0082331
2019-02-25 13:47 oan Assigned To oan => msv
2019-02-25 13:47 oan Status assigned => resolved
2019-02-25 13:48 oan Relationship added related to 0030511
2019-02-27 16:56 msv Note Added: 0082422
2019-02-27 16:56 msv Assigned To msv => oan
2019-02-27 16:56 msv Status resolved => assigned
2019-02-28 10:01 git Note Added: 0082438
2019-02-28 10:06 oan Relationship added parent of 0030528
2019-02-28 10:07 oan Note Added: 0082440
2019-02-28 10:07 oan Assigned To oan => msv
2019-02-28 10:07 oan Status assigned => resolved
2019-02-28 10:58 git Note Added: 0082444
2019-02-28 11:03 git Note Added: 0082445
2019-02-28 15:03 msv Note Added: 0082456
2019-02-28 15:03 msv Assigned To msv => bugmaster
2019-02-28 15:03 msv Status resolved => reviewed
2019-02-28 16:05 apn Test case number => bugs moddata_3 bug30497
2019-02-28 18:35 apn Note Added: 0082469
2019-02-28 18:35 apn Status reviewed => tested
2019-03-03 21:12 apn Changeset attached => occt master 967d2f4f
2019-03-03 21:12 apn Assigned To bugmaster => apn
2019-03-03 21:12 apn Status tested => verified
2019-03-03 21:12 apn Resolution open => fixed
2019-03-05 13:46 git Note Added: 0082645
2019-03-05 13:46 git Note Added: 0082646
2019-03-05 13:46 git Note Added: 0082647
2019-03-05 13:47 git Note Added: 0082648


Copyright © 2000 - 2019 MantisBT Team
Powered by Mantis Bugtracker