MantisBT
Mantis Bug Tracker Workflow

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0026612Community[OCCT] OCCT:Visualizationpublic2015-08-27 16:062016-06-29 11:06
ReporterAlexanderZashivalov 
Assigned Tobugmaster 
PrioritynormalSeverityminor 
StatusclosedResolutionunable to reproduce 
PlatformOSOS Version
Product Version[OCCT] 6.9.0 
Target VersionFixed in Version 
Summary0026612: High memory footprint displaying model with big amount of solids
DescriptionWhen model has big number of solids (5000+) the memory footprint used to display it with TKOpenGL is too high. About 240 Kb for one simple sphere.
Steps To Reproduce1. Run DRAW.
Private memory is 9.4 Mb (see init.png).
2. Create 5000 spheres. Use script:
for {psphere s 5; set i 1} {$i <= 5000} {incr i} { tcopy s s$i; ttranslate s$i $i*11 0 0 }
Private memory is 28.26 Mb (see vars.png).
3. Display them in AIS viewer. Use script:
for {set i 1} {$i <= 5000} {incr i} {vdisplay s$i}
Private memory is 1.17 Gb (see disp.png).
Additional information
and documentation updates
This is not a very rare situation for real world models to have big number of solids (more then 10000) and they are not just spheres. For example, building plans or pipe systems. Trying to view them with AIS viewer takes 4+ Gb of memory which kills application.
TagsNo tags attached.
Test case number
Attached Filespng file icon init.png (102,980 bytes) 2015-08-27 16:06
png file icon vars.png (105,670 bytes) 2015-08-27 16:07
png file icon disp.png (407,174 bytes) 2015-08-27 16:07
png file icon Draw_spheres.png (38,727 bytes) 2016-06-28 17:11

- Relationships
related to 0026885closedbugmaster Open CASCADE Visualization - drop redundant aspects from structure level 
related to 0027596closedbugmaster Open CASCADE Visualization, StdPrs_WFShape - pack isolines into single group of primitives 

-  Notes
(0044761)
Roman Lygin (developer)
2015-08-27 17:22

Just an extra note: this is a synthetic reproducer of a few real world cases of large assemblies that cannot be displayed in CAD Exchanger GUI. The app runs out of memory even on 64 bit systems - after taking >4GB the app cannot allocate memory and crashes.

These assemblies consist of a few dozens of thousands of solids (up to 50-100K).

Very rough approximation is for 1MB of original TopoDS_Shape in memory, it takes ~0.8MB of Poly_Triangulation after BRepMesher. When trying to display this (even without enabled selection) it takes 1-3 MB for each original MB of B-Rep.

The reproducer above is an attempt to reproduce this excessive footprint in DRAW.

This issue seriously affects usability of visualization of complex real-world models. Enabling selection adds further extra overhead of comparable (or even greater) footprint.
(0055477)
kgv (developer)
2016-06-25 14:51

It is something missing in the bug description.
The test case does not corresponds to the screenshot state and actual numbers differ.

I have tried to restore test script:
pload MODELING VISUALIZATION
vclear
vclose ALL

meminfo
for {psphere s 5; set i 1} {$i <= 5000} {incr i} { tcopy s s$i; ttranslate s$i $i*11 0 0 }
meminfo

vinit View1
vsetdispmode 0
for {set i 1} {$i <= 5000} {incr i} {vdisplay -noupdate s$i}
vfit
vsetdispmode 1
meminfo

#vclear
#meminfo


Here are the final numbers on OCCT 6.9.0 (vc10 win64):
  Private memory:     678 MiB
  Working Set:        685 MiB (peak: 768 MiB)
  Pagefile usage:     678 MiB (peak: 761 MiB)
  Virtual memory:     979 MiB
  Heap memory:     452 MiB


and on current master (vc12 win64):
  Private memory:     644 MiB
  Working Set:        645 MiB (peak: 733 MiB)
  Pagefile usage:     644 MiB (peak: 732 MiB)
  Virtual memory:     904 MiB
  Heap memory:     519 MiB


This is very far from 1.17 Gb in original description.
(0055549)
AlexanderZashivalov (developer)
2016-06-28 17:10

Hi, Kirill. Thank you for analysis.
I've tested the 7.0.0 version in release mode built w/ vc14. The numbers are indeed another, ~750Mb. See latest attached screenshot. This footprint is comparable to 3DS Max where same scenario takes ~650Mb. So it seems the issue is not relevant any more.
(0055550)
kgv (developer)
2016-06-28 17:21

Dear bugmaster,

please close the issue.

The memory usage improvements might be done in OCCT, but in general, models defining very big amounts of objects should be displayed using other approach.

- Issue History
Date Modified Username Field Change
2015-08-27 16:06 AlexanderZashivalov New Issue
2015-08-27 16:06 AlexanderZashivalov Assigned To => kgv
2015-08-27 16:06 AlexanderZashivalov File Added: vars.png
2015-08-27 16:06 AlexanderZashivalov File Deleted: vars.png
2015-08-27 16:06 AlexanderZashivalov File Added: init.png
2015-08-27 16:07 AlexanderZashivalov File Added: vars.png
2015-08-27 16:07 AlexanderZashivalov File Added: disp.png
2015-08-27 17:22 Roman Lygin Note Added: 0044761
2016-06-17 15:05 kgv Relationship added related to 0026885
2016-06-17 15:07 kgv Relationship added related to 0027596
2016-06-25 14:51 kgv Note Added: 0055477
2016-06-25 14:51 kgv Assigned To kgv => Alexander Schneller
2016-06-25 14:51 kgv Status new => feedback
2016-06-25 14:52 kgv Assigned To Alexander Schneller => AlexanderZashivalov
2016-06-25 14:54 kgv Resolution open => unable to reproduce
2016-06-28 17:10 AlexanderZashivalov Note Added: 0055549
2016-06-28 17:11 AlexanderZashivalov File Added: Draw_spheres.png
2016-06-28 17:21 kgv Note Added: 0055550
2016-06-28 17:21 kgv Assigned To AlexanderZashivalov => bugmaster
2016-06-29 11:06 bugmaster Status feedback => closed


Copyright © 2000 - 2019 MantisBT Team
Powered by Mantis Bugtracker