Your message dated Wed, 27 Feb 2013 22:40:02 +0100
with message-id <[email protected]>
and subject line closing bug#676967: openscad: very large memory consumption 
for CSG[...]
has caused the Debian Bug report #676967,
regarding openscad: very large memory consumption for CSG rendering of a simple 
object leading to kill the process
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
676967: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676967
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: openscad
Version: 2012.05~.12-git67eb2ebe-1
Severity: normal

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?

Rendering a specific script representing a small object.

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

I loaded the attached script. Rendering it using CGAL by hitting the F6 key
works perfectly and displays a results in less than one minute. Rendering it
using CSG rendering by hitting the F5 key triggerred the problem.

   * What was the outcome of this action?

CGAL rendering displayed a correct result in less than one minute.
CSG rendering started consuming lots of memory (memory consumption was
increasing linearly in time). When RAM was filled up, swap started to be used,
with extremelly intensive disk activity and memory still increasing. I finally
killed the process after more than 40 minutes and 5 gigabytes memory being
used, without seeing any rendering.

The problem seems to be related with rendering the result of the difference()
operation in the bottom_part module.

I was able to display something with CSG on this script only when reducing a
lot the object, by changing the number of row and columns to extremelly small
numbers (2 or 3). Note that the problem still occurs, but after a few minutes,
at least something happens and I get an error message about a tree being too
large (more than a few thousands nodes). The original script which I
interrupted after 40 minutes uses 6 rows and 5 columns in the design, which is
still a simple object.

   * What outcome did you expect instead?

I expected both rendering (CGAL and CSG) to provide similar results in
approximately the same time.

*** End of the template - remove these lines ***



-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages openscad depends on:
ii  libboost-filesystem1.49.0       1.49.0-3
ii  libboost-program-options1.49.0  1.49.0-3
ii  libboost-regex1.49.0            1.49.0-3
ii  libboost-system1.49.0           1.49.0-3
ii  libboost-thread1.49.0           1.49.0-3
ii  libc6                           2.13-33
ii  libcgal9                        4.0-2
ii  libgcc1                         1:4.7.0-8
ii  libgl1-mesa-glx [libgl1]        8.0.2-2
ii  libglew1.7                      1.7.0-3
ii  libglu1-mesa [libglu1]          8.0.2-2
ii  libgmp10                        2:5.0.5+dfsg-1.1
ii  libmpfr4                        3.1.0-5
ii  libopencsg1                     1.3.2-2
ii  libqt4-opengl                   4:4.8.1-1
ii  libqtcore4                      4:4.8.1-1
ii  libqtgui4                       4:4.8.1-1
ii  libstdc++6                      4.7.0-8

openscad recommends no packages.

Versions of packages openscad suggests:
pn  geomview  <none>
pn  librecad  <none>
pn  meshlab   <none>

-- no debconf information

*** /home/luc/reprap/honeycomb.scad
// copyright misty soul 2012
// distributed under the terms of the
// CreativeCommons Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0)


// beware, it seems trying to render this with CSG under OpenScad takes
// ages and consumes lots of memory (I had to interrupt OpenScad after 40
minutes
// and the process was consuming more than 5 gigabytes memory). It does render
// well using CGAL under OpenScad

// number of rows and columns, beware that some hexagonal cells are clipped
// at rectangular box boundaries, so the total number of cells will be
// smaller than rows * columns
rows          = 6;
columns       = 5;

// cell step is hole size between opposite hexagon walls plus inner wall
thickness
cell_step     = 30;

// inner depth of the hexagonal boxes
height        = 25;

// walls thickness
inner_walls   = 2;
outer_walls   = 3;

// this clearance should allow fitting of the lid over the bottom box
lid_clearance = 1;

// how far does the lid protrube inside the bottom box
lid_depth     = 10;

module hexagon(size, height) {
    intersection_for(angle = [0 : 60 : 120]) {
        rotate(angle)
        cube(size = [size, 2 * size, height], center = true);
    }
}

module honeycomb_row(cells, cell_step, inner_walls, height) {
    for (j = [0 : cells - 1]) {
        translate([j * cell_step, 0, 0])
        hexagon(cell_step - inner_walls, height);
    }
}

module full_honeycomb(rows, columns, cell_step, inner_walls, height) {
    for (i = [0 : rows - 1]) {
        translate([(i % 2) * cell_step / 2, cell_step * i * sqrt(3) / 2, 0])
        honeycomb_row(columns, cell_step, inner_walls, height);
    }
}

module clipped_honeycomb(rows, columns, cell_step, inner_walls, height) {
    intersection() {
        cube([(columns - 1) * cell_step, (rows - 1) * cell_step * sqrt(3) / 2,
height]);
        full_honeycomb(rows, columns, cell_step, inner_walls, 3 * height);
    }
}

module bottom_part(rows, columns, cell_step, inner_walls, outer_walls, height)
{
    translate([0, 0, outer_walls])
    difference() {
        translate([-outer_walls, -outer_walls, -outer_walls])
        cube([(columns - 1) * cell_step + 2 * outer_walls,
              (rows - 1) * cell_step * sqrt(3) / 2 + 2 * outer_walls,
              height + outer_walls]);
        clipped_honeycomb(rows, columns, cell_step, inner_walls, 2 * height);
    }
}

module top_part(rows, columns, cell_step, inner_walls, outer_walls, height,
lid_clearance) {
    translate([-(cell_step + outer_walls), 0, height + 2 * outer_walls])
    rotate([0,180,0])
    difference() {
        translate([-((2 * outer_walls) + lid_clearance),
                   -((2 * outer_walls) + lid_clearance),
                   height + outer_walls - lid_depth])
            cube([(columns - 1) * cell_step + 4 * outer_walls + 2 *
lid_clearance,
                  (rows - 1) * cell_step * sqrt(3) / 2 + 4 * outer_walls + 2 *
lid_clearance,
                  outer_walls + lid_depth]);
        bottom_part(rows,columns, cell_step, inner_walls + lid_clearance,
outer_walls + lid_clearance, height);
    }
}

//bottom_part(rows, columns, cell_step, inner_walls, outer_walls, height);

top_part(rows, columns, cell_step, inner_walls, outer_walls, height,
lid_clearance);



--- End Message ---
--- Begin Message ---
notfound 676967 2013.01+dfsg-1
notfound 676967 2013.01+dfsg-2
thank you

the fix described in the upstream bug tracker has been included in
debian packages since the 2013.01 releases (and was forgotten to mention
in the changelog).

to the best of my understanding, the underlying issue of some operations
taking long time is not solved (or can't be solved), but some resource
usage constraints are now in place, and fallback behavior is triggered.

please also see the author's comment on optimizing your model at [1] in
order to avoid needing the fallback behavior.

[1] https://github.com/openscad/openscad/issues/127#issuecomment-6384867

Attachment: signature.asc
Description: Digital signature


--- End Message ---

Reply via email to