MantisBT
Mantis Bug Tracker Workflow

View Issue Details Jump to Notes ] Related Changesets ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0030511Open CASCADE[OCCT] OCCT:Meshpublic2019-02-21 17:362019-07-09 14:53
Reporterabv 
Assigned Toapn 
PrioritynormalSeverityminor 
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Version[OCCT] 7.4.0Fixed in Version[OCCT] 7.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? file icon hugeassembly0.brep (45,852 bytes) 2019-02-21 17:41
png file icon hige-brep.png (378,672 bytes) 2019-02-22 09:49
png file icon huge-step.png (378,327 bytes) 2019-02-22 09:49
png file icon cad_assistant_1.0-2018-02-14.png (230,808 bytes) 2019-02-22 12:54
png file icon cad_assistant_1.1-2018-09-11.png (396,579 bytes) 2019-02-22 12:54
png file icon cad_assistant_1.3-2019-02-11.png (335,557 bytes) 2019-02-22 12:54

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

-  Notes
(0082284)
oan (developer)
2019-02-21 18:45

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.
(0082298)
oan (developer)
2019-02-22 12:54

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.
(0082320)
abv (manager)
2019-02-23 21:51

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.
(0082336)
oan (developer)
2019-02-25 14:06
edited on: 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.

(0082573)
git (administrator)
2019-03-04 09:46

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.
(0082574)
oan (developer)
2019-03-04 09:48

Andrey,

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

Branch CR30511 contains test case only.

Please review.
(0082757)
kgv (developer)
2019-03-07 12:18

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
(0082758)
oan (developer)
2019-03-07 12:28

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.
(0082759)
kgv (developer)
2019-03-07 12:37

> 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.
(0082760)
oan (developer)
2019-03-07 12:55

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.
(0082874)
kgv (developer)
2019-03-12 14:48
edited on: 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.

(0082875)
msv (developer)
2019-03-12 15:20

Reviewed.
(0082921)
git (administrator)
2019-03-13 16:44

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

(0083008)
git (administrator)
2019-03-15 19:16

Branch CR30511 has been updated forcibly by apn.

SHA-1: bbd9ac8498eb56047793be84bd4c26c1ed12f124
(0083074)
git (administrator)
2019-03-19 10:32

Branch CR30511 has been deleted by inv.

SHA-1: bbd9ac8498eb56047793be84bd4c26c1ed12f124
(0085508)
abv (manager)
2019-07-09 14:53

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
Timestamp: 2019-03-04 06:41:34
Author: oan
Committer: apn
Details ] Diff ]
0030511: Mesh - too long meshing of assembly containing single solid (shared)

Added test case.
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 View Revisions
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 View Revisions
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 View Revisions
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


Copyright © 2000 - 2019 MantisBT Team
Powered by Mantis Bugtracker