View Issue Details

IDProjectCategoryView StatusLast Update
0030511Open CASCADEOCCT:Meshpublic2019-07-09 14:53
ReporterabvAssigned Toapn  
PrioritynormalSeverityminor 
Status closedResolutionfixed 
Target Version7.4.0Fixed in Version7.4.0 
Summary0030511: Mesh - too long meshing of assembly containing single solid (shared)
DescriptionAttached BREP file contains assembly where single solid (box) is replicated ~ 93000 times. Meshing of this shape takes ~ 30 sec, which looks too much since the actual geometry is just a box.
Steps To Reproducepload MODELING
restore [locate_data_file hugeassembly0.brep] a
nbshapes a
dchrono s restart
incmesh a 0.1
dchrono s stop show
TagsNo tags attached.
Test case numberbugs mesh bug30511

Attached Files

  • hugeassembly0.brep (45,852 bytes)
  • hige-brep.png (378,672 bytes)
  • huge-step.png (378,327 bytes)
  • cad_assistant_1.0-2018-02-14.png (230,808 bytes)
  • cad_assistant_1.1-2018-09-11.png (396,579 bytes)
  • cad_assistant_1.3-2019-02-11.png (335,557 bytes)

Relationships

related to 0030497 closedapn [REGRESSION] Mesh - wrong Poly_Polygon3D within local selection of located shape 

Activities

abv

2019-02-21 17:41

manager  

hugeassembly0.brep (45,852 bytes)

oan

2019-02-21 18:45

developer   ~0082284

Andrey,

Generally, comparing to OCCT 7.3.0 there is a significant performance improvement on this case on my machine:

OCCT 7.3.0:
41.21642 Seconds
This shape contains 1119744 triangles

current master:
25.2386381 Seconds
This shape contains 1119744 triangles

However, could you please express your considerations why it should be faster in more detail rather than pure statement that it is just boxes, it seems subjective as far as there are 93312 distinct shapes whatever kind they are and it is a challenging task to process such a huge number of shapes anyway.

Mesher explodes entire model on edges and processes them, then explodes entire model on faces and processes them. So, the greater number of unique edges and unique faces the more time needed to process entire model, it is logical.

Moreover, I know use case when it works much more slower even on a single shape:
psphere s 1000
incmesh s 0.001

Production of 1119744 triangles even on a single shape is always a resource intensive task.

What performance do you expect finally, please specify?
Elsewhere we ought to go to no-ending optimization, probably without possibility to achieve better goals.

For attached model the best solution to achive universe performance is to use shapes with shared TShape and different locations.

In this case performance should be equal to time needed to process only one box.

kgv

2019-02-22 09:49

developer  

hige-brep.png (378,672 bytes)

kgv

2019-02-22 09:49

developer  

huge-step.png (378,327 bytes)

oan

2019-02-22 12:54

developer   ~0082298

Kirill,

thanks for screenshots, I have checked behaviour on various versions of CAD Assistant using attached BRep file and seems it is actual even on earlier versions of OCCT.

However, it is 20 seconds faster since CAD Assistant version 1.1 (see additional screenshots). Maybe due to revision of BRepMesh.

Newertheless, here we should specify what performance is expected.
I suppose we can go in different way rather than performance improvement of BRepMesh, probably, we can simplify it in order to replace similar parts by instances with different locations.

oan

2019-02-22 12:54

developer  

cad_assistant_1.0-2018-02-14.png (230,808 bytes)

oan

2019-02-22 12:54

developer  

cad_assistant_1.1-2018-09-11.png (396,579 bytes)

oan

2019-02-22 12:54

developer  

cad_assistant_1.3-2019-02-11.png (335,557 bytes)

abv

2019-02-23 21:51

manager   ~0082320

Oleg, this shape contains 1 (one) box solid, shared many times within the assembly structure. Since it is still the same single box, it should be triangulated very fast unless it is either triangulated 93 K times or there are some enormous overhead expenses.

oan

2019-02-25 14:06

developer   ~0082336

Last edited: 2019-02-25 14:07

Andrey,

OK, according to 0030497, seems that BRepMesh spends the most of processing time on extraction and tessellation of edges of the model.

The matter is that all edges are added to the model despite of the fact that they share the same TEdge, because of different locations.

However, only faces with unique TFace are used for further processing.
Due to this fact model contains entire set of edges, but only unique faces, so some edges can be left unused within discrete model. Nevertheless, by design all edges are tessellated despite of relation to any face.

Patch 0030497 improves performance of this case up to ~ 3.5 secs.

I suppose it can be closed after integration of that fix.

git

2019-03-04 09:46

administrator   ~0082573

Branch CR30511 has been created by oan.

SHA-1: 69e89a52f1177dee86ec57ddf1ce12d0ff55318c


Detailed log of new commits:

Author: oan
Date: Mon Mar 4 09:41:34 2019 +0300

    0030511: Mesh - too long meshing of assembly containing single solid (shared)
    
    Added test case.

oan

2019-03-04 09:48

developer   ~0082574

Andrey,

to my mind, issue has been completely fixed by 0030497.

Branch CR30511 contains test case only.

Please review.

kgv

2019-03-07 12:18

developer   ~0082757

Another funny script:
pload MODELING VISUALIZATION
set nx 50; set ny 50; set nz 50;
set bb {}
for {set x 1} {$x <= $nx} {incr x} { for {set y 1} {$y <= $ny} {incr y} { for {set z 1} {$z <= $nz} {incr z} { box b${x}_${y}_${z} $x $y $z 0.5 0.5 0.5; lappend bb b${x}_${y}_${z} } } }

meminfo
dchrono t stop;dchrono t reset;dchrono t start
# meshing Compound instead of independent boxes (they are all independent)
# is a heck of slow...
#compound {*}$bb cc; incmesh cc 0.001 -parallel
for {set x 1} {$x <= $nx} {incr x} { for {set y 1} {$y <= $ny} {incr y} { for {set z 1} {$z <= $nz} {incr z} { box b${x}_${y}_${z} $x $y $z 0.5 0.5 0.5; incmesh b${x}_${y}_${z} 0.001 } } }
dchrono t stop;dchrono t show
meminfo

oan

2019-03-07 12:28

developer   ~0082758

Hi Kirill,

the last script represents different case comparing to reported problem.
Initial one is fixed by 0030497.

So please report new issue and we will consider it in further.

kgv

2019-03-07 12:37

developer   ~0082759

> the last script represents different case comparing to reported problem.
Sure, just shared some new scripts, not sure if it is critical to analyze it.

oan

2019-03-07 12:55

developer   ~0082760

Maybe it is not critical, but it would be better if we will have as much use cases as possible anyway.

You know that such approach allows to maintain the component much more stable than without it.

So, thanks for an additional use case.

kgv

2019-03-12 14:48

developer   ~0082874

Last edited: 2019-03-12 14:49

> Maybe it is not critical, but it would be better
> if we will have as much use cases as possible anyway.
> So, thanks for an additional use case.
pload MODELING VISUALIZATION
set nx 50; set ny 50; set nz 10;
set bb {}
for {set x 1} {$x <= $nx} {incr x} { for {set y 1} {$y <= $ny} {incr y} { for {set z 1} {$z <= 
$nz} {incr z} { box b${x}_${y}_${z} $x $y $z 0.5 0.5 0.5; lappend bb b${x}_${y}_${z} } } }
compound {*}$bb cc

# meshing as individual objects
tclean cc
dchrono t stop;dchrono t reset;dchrono t start
for {set x 1} {$x <= $nx} {incr x} { for {set y 1} {$y <= $ny} {incr y} { for {set z 1} {$z <= 
$nz} {incr z} { box b${x}_${y}_${z} $x $y $z 0.5 0.5 0.5; incmesh b${x}_${y}_${z} 0.001 } } }
dchrono t stop;dchrono t show

# meshing as compound, parallel OFF
tclean cc
dchrono t stop;dchrono t reset;dchrono t start
incmesh cc 0.001
dchrono t stop;dchrono t show

# meshing as compound, parallel ON
tclean cc
dchrono t stop;dchrono t reset;dchrono t start
incmesh cc 0.001 -parallel
dchrono t stop;dchrono t show


On current master:
# meshing as individual objects
Elapsed time: 0 Hours 0 Minutes 37.8191607763 Seconds
CPU user time: 18.203125 seconds
CPU system time: 19.234375 seconds

# meshing as compound, parallel OFF
Elapsed time: 0 Hours 0 Minutes 34.7572358875 Seconds
CPU user time: 16.015625 seconds
CPU system time: 18.375 seconds

# meshing as compound, parallel ON
Elapsed time: 0 Hours 0 Minutes 23.2027255736 Seconds
CPU user time: 49.609375 seconds
CPU system time: 56.125 seconds

So OK, there is no more such issue.

msv

2019-03-12 15:20

developer   ~0082875

Reviewed.

git

2019-03-13 16:44

administrator   ~0082921

Branch CR30511 has been updated by apn.

SHA-1: 83228e33339528695d274ed48fa0e55383761271


Detailed log of new commits:

Author: apn
Date: Wed Mar 13 16:38:55 2019 +0300

    //Correct test case

git

2019-03-15 19:16

administrator   ~0083008

Branch CR30511 has been updated forcibly by apn.

SHA-1: bbd9ac8498eb56047793be84bd4c26c1ed12f124

git

2019-03-19 10:32

administrator   ~0083074

Branch CR30511 has been deleted by inv.

SHA-1: bbd9ac8498eb56047793be84bd4c26c1ed12f124

abv

2019-07-09 14:53

manager   ~0085508

I confirm that on current master the time of execution of the reproducer script is much less than in 7.3.0 (2.5 sec vs. 31 sec).

Related Changesets

occt: master ad4b0429

2019-03-04 06:41:34

oan


Committer: apn Details Diff
0030511: Mesh - too long meshing of assembly containing single solid (shared)

Added test case.
Affected Issues
0030511
add - tests/perf/mesh/bug30511 Diff File

Issue History

Date Modified Username Field Change
2019-02-21 17:36 abv New Issue
2019-02-21 17:36 abv Assigned To => oan
2019-02-21 17:41 abv File Added: hugeassembly0.brep
2019-02-21 18:45 oan Note Added: 0082284
2019-02-21 18:45 oan Assigned To oan => abv
2019-02-21 18:45 oan Status new => feedback
2019-02-22 09:49 kgv File Added: hige-brep.png
2019-02-22 09:49 kgv File Added: huge-step.png
2019-02-22 12:54 oan Note Added: 0082298
2019-02-22 12:54 oan File Added: cad_assistant_1.0-2018-02-14.png
2019-02-22 12:54 oan File Added: cad_assistant_1.1-2018-09-11.png
2019-02-22 12:54 oan File Added: cad_assistant_1.3-2019-02-11.png
2019-02-23 21:49 abv Assigned To abv => oan
2019-02-23 21:51 abv Note Added: 0082320
2019-02-25 13:48 oan Relationship added related to 0030497
2019-02-25 14:06 oan Note Added: 0082336
2019-02-25 14:06 oan Assigned To oan => abv
2019-02-25 14:07 oan Note Edited: 0082336
2019-03-04 09:46 git Note Added: 0082573
2019-03-04 09:48 oan Note Added: 0082574
2019-03-04 09:48 oan Status feedback => resolved
2019-03-07 12:18 kgv Note Added: 0082757
2019-03-07 12:28 oan Note Added: 0082758
2019-03-07 12:37 kgv Note Added: 0082759
2019-03-07 12:55 oan Note Added: 0082760
2019-03-07 13:22 oan Assigned To abv => msv
2019-03-12 14:48 kgv Note Added: 0082874
2019-03-12 14:49 kgv Note Edited: 0082874
2019-03-12 15:20 msv Note Added: 0082875
2019-03-12 15:20 msv Assigned To msv => bugmaster
2019-03-12 15:20 msv Status resolved => reviewed
2019-03-12 16:25 apn Test case number => bugs mesh bug30511
2019-03-12 16:25 apn Status reviewed => tested
2019-03-13 16:44 git Note Added: 0082921
2019-03-15 18:19 abv Steps to Reproduce Updated
2019-03-15 19:16 git Note Added: 0083008
2019-03-17 15:40 apn Changeset attached => occt master ad4b0429
2019-03-17 15:40 apn Assigned To bugmaster => apn
2019-03-17 15:40 apn Status tested => verified
2019-03-17 15:40 apn Resolution open => fixed
2019-03-19 10:32 git Note Added: 0083074
2019-07-09 14:53 abv Note Added: 0085508