View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0030511 | Open CASCADE | OCCT:Mesh | public | 2019-02-21 17:36 | 2019-07-09 14:53 |
Reporter | Assigned To | apn | |||
Priority | normal | Severity | minor | ||
Status | closed | Resolution | fixed | ||
Target Version | 7.4.0 | Fixed in Version | 7.4.0 | ||
Summary | 0030511: Mesh - too long meshing of assembly containing single solid (shared) | ||||
Description | Attached 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 Reproduce | pload MODELING restore [locate_data_file hugeassembly0.brep] a nbshapes a dchrono s restart incmesh a 0.1 dchrono s stop show | ||||
Tags | No tags attached. | ||||
Test case number | bugs mesh bug30511 | ||||
2019-02-21 17:41 manager |
hugeassembly0.brep (45,852 bytes) |
|
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. |
|
hige-brep.png (378,672 bytes) |
|
huge-step.png (378,327 bytes) |
|
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. |
|
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) |
|
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. |
|
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. |
|
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. |
|
Andrey, to my mind, issue has been completely fixed by 0030497. Branch CR30511 contains test case only. Please review. |
|
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 |
|
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. |
|
> 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. |
|
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. |
|
> 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. |
|
Reviewed. |
|
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 |
|
Branch CR30511 has been updated forcibly by apn. SHA-1: bbd9ac8498eb56047793be84bd4c26c1ed12f124 |
|
Branch CR30511 has been deleted by inv. SHA-1: bbd9ac8498eb56047793be84bd4c26c1ed12f124 |
|
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). |
Date Modified | Username | Field | Change |
---|---|---|---|
2019-02-21 17:36 |
|
New Issue | |
2019-02-21 17:36 |
|
Assigned To | => oan |
2019-02-21 17:41 |
|
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 |
|
Assigned To | abv => oan |
2019-02-23 21:51 |
|
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 |
|
Note Added: 0082875 | |
2019-03-12 15:20 |
|
Assigned To | msv => bugmaster |
2019-03-12 15:20 |
|
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 |
|
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 |
|
Note Added: 0085508 |