View Issue Details

Related ChangesetsJump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0030497Open CASCADEOCCT:Meshpublic2019-02-15 09:302019-03-05 13:47
Reporternds Assigned Toapn  
PrioritynormalSeveritymajor 
Status closedResolutionfixed 
Product Version7.4.0 
Target Version7.4.0Fixed in Version7.4.0 
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 Files

  • located_shape_wrong_position.png (10,796 bytes)
  • as1-oc-214-mat.stp (445,345 bytes)
  • s730_OK.brep (401,373 bytes)
  • s740dev_KO.brep (438,035 bytes)

Relationships

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

Activities

nds

2019-02-15 09:30

developer  

located_shape_wrong_position.png (10,796 bytes)

nds

2019-02-15 09:36

developer   ~0082190

Last edited: 2019-02-15 09:38

 This DRAW scenario starts reproducing with the fix for 0026106 (7bd071edb13e5aa7a1d3aed4ed4366fe3da83324).
On the previous commit it works correct (80da8585f4351470d5034519a8468a88bd12a819).

nds

2019-02-15 09:37

developer  

as1-oc-214-mat.stp (445,345 bytes)

kgv

2019-02-15 12:29

developer  

s730_OK.brep (401,373 bytes)

kgv

2019-02-15 12:29

developer  

s740dev_KO.brep (438,035 bytes)

kgv

2019-02-15 12:31

developer   ~0082193

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.

oan

2019-02-15 16:22

developer   ~0082198

Last edited: 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.

git

2019-02-19 14:03

administrator   ~0082222

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

git

2019-02-20 16:18

administrator   ~0082239

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.

git

2019-02-21 11:11

administrator   ~0082269

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

nds

2019-02-21 11:19

developer   ~0082270

Dear Mikhail,
could you please review modifications.

Job on Jenkins is http://vm-jenkins-test-12.nnov.opencascade.com:8080/view/CR30497-master-NDS/.

msv

2019-02-21 17:02

developer   ~0082277

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.

git

2019-02-21 18:02

administrator   ~0082281

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

oan

2019-02-21 19:03

developer   ~0082285

Last edited: 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.

git

2019-02-22 07:12

administrator   ~0082286

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.

git

2019-02-22 09:13

administrator   ~0082287

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

nds

2019-02-22 13:55

developer   ~0082301

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/

msv

2019-02-22 16:47

developer   ~0082307

Oleg, you did not understand the root of the problem. The fix is correct.

msv

2019-02-22 16:48

developer   ~0082308

Reviewed.

msv

2019-02-22 16:52

developer   ~0082310

Last edited: 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.

msv

2019-02-22 17:14

developer   ~0082311

Dear Oleg, could you complete the fix?

git

2019-02-22 19:07

administrator   ~0082313

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.

git

2019-02-25 11:35

administrator   ~0082325

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.

git

2019-02-25 11:53

administrator   ~0082326

Branch CR30497_2 has been updated forcibly by oan.

SHA-1: a6a38928adcbdfdbd0bc92978f41cc1875da6593

oan

2019-02-25 13:47

developer   ~0082331

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.

msv

2019-02-27 16:56

developer   ~0082422

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.

git

2019-02-28 10:01

administrator   ~0082438

Branch CR30497_2 has been updated forcibly by oan.

SHA-1: 73443a06be92dcf7f974647ea2096f7b84774154

oan

2019-02-28 10:07

developer   ~0082440

Done.

git

2019-02-28 10:58

administrator   ~0082444

Branch CR30497_2 has been updated forcibly by oan.

SHA-1: 53298de03e88a2f30e4f9f73a872f47a36d88c83

git

2019-02-28 11:03

administrator   ~0082445

Branch CR30497_2 has been updated forcibly by oan.

SHA-1: 643073552db0bfdde903a577bcd00f0658c123e3

msv

2019-02-28 15:03

developer   ~0082456

Reviewed.

apn

2019-02-28 18:35

administrator   ~0082469

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

git

2019-03-05 13:46

administrator   ~0082645

Branch CR30497 has been deleted by kgv.

SHA-1: ef39d5f7b91a115ac0ec69f86fa1ba73e2395244

git

2019-03-05 13:46

administrator   ~0082646

Branch CR30497_1 has been deleted by kgv.

SHA-1: dfc0e690b3dfb3ab6e1c67ee5ce748c02f1f4949

git

2019-03-05 13:46

administrator   ~0082647

Branch CR30497_2 has been deleted by kgv.

SHA-1: 643073552db0bfdde903a577bcd00f0658c123e3

git

2019-03-05 13:47

administrator   ~0082648

Branch CR30497_3 has been deleted by kgv.

SHA-1: b8024f2441dc7ef3b8ed839e6382ebf3e5fc8423

Related Changesets

occt: master 967d2f4f

2019-02-28 06:55:53

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.		 Affected Issues
0030497
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
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
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
2019-02-15 16:23 oan Note Edited: 0082198
2019-02-15 16:25 oan Note Edited: 0082198
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
2019-02-21 19:25 oan Note Edited: 0082285
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
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