Changes to CGAL datastructures? Memory use.
OpenSCAD 2015.03-2/64
When fiddling with the surface issue
https://github.com/openscad/openscad/issues/1535 doing
union()
{
translate([-5,0,5]) cube(1);
surface(file = "model.data", center = true, invert = false);
}
It goes to nearly 3GB working set when rendering. It is a nearly 300x300
surface.
But the stats don't seem that big
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
Geometries in cache: 5
Geometry cache size in bytes: 71198536
CGAL Polyhedrons in cache: 2
CGAL cache size in bytes: 469181312
Total rendering time: 0 hours, 5 minutes, 53 seconds
Top level object is a 3D object:
Simple: yes
Vertices: 105562
Halfedges: 543928
Edges: 271964
Halffacets: 332808
Facets: 166404
Volumes: 2
Rendering finished.
And there is definitely memory leaks, when re-rendering, after adding a
rotate & scale(1) the commit size got close to 8GB (fairly quickly). It then
crashed.
Newly minted Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
View this message in context: http://forum.openscad.org/Changes-to-CGAL-datastructures-Memory-use-tp15531.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Hi,
I thought your case was interesting. It makes little sense that 3GB
memory is required for rendering a surface of less than 300x300 data points.
I downloaded your file and tried to replicate your model:
http://arnholm.org/software/as_csg/surface/surface_file.png
As you can see, it renders in 30 seconds in OpenSCAD without any
problems after generating it with AngelScript CSG:
http://arnholm.org/software/as_csg/surface/surface_file.as
(the feature to read surface data from file is new)
Running the script to generate the OpenSCAD .csg took 1 second:
http://arnholm.org/software/as_csg/surface/surface_file_compilation.png
The OpenSCAD .csg file generated:
http://arnholm.org/software/as_csg/surface/surface_file.csg
After exporting to STL, it was checked in KISSlicer, no errors.
I don't know the details on how OpenSCAD internally represents and
processes surface data read from file, but if one simply generates a
lofted surface from the data points and then a polyhedron from that like
in this case it works fairly well, as would be expected.
Carsten Arnholm
On 07. jan. 2016 06:49, MichaelAtOz wrote:
OpenSCAD 2015.03-2/64
When fiddling with the surface issue
https://github.com/openscad/openscad/issues/1535 doing
union()
{
translate([-5,0,5]) cube(1);
surface(file = "model.data", center = true, invert = false);
}
It goes to nearly 3GB working set when rendering. It is a nearly 300x300
surface.
But the stats don't seem that big
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
Geometries in cache: 5
Geometry cache size in bytes: 71198536
CGAL Polyhedrons in cache: 2
CGAL cache size in bytes: 469181312
Total rendering time: 0 hours, 5 minutes, 53 seconds
Top level object is a 3D object:
Simple: yes
Vertices: 105562
Halfedges: 543928
Edges: 271964
Halffacets: 332808
Facets: 166404
Volumes: 2
Rendering finished.
And there is definitely memory leaks, when re-rendering, after adding a
rotate & scale(1) the commit size got close to 8GB (fairly quickly). It then
crashed.
On Jan 7, 2016, at 15:05 PM, Carsten Arnholm arnholm@arnholm.org wrote:
I don't know the details on how OpenSCAD internally represents and processes surface data read from file, but if one simply generates a lofted surface from the data points and then a polyhedron from that like in this case it works fairly well, as would be expected.
A stand-alone surface() is fast as it’s just a polygon mesh and we don’t need to touch CGAL. The issues happen when we do CSG ops on it - we then need to convert it into CGAL data structures, and CGAL subsequently uses a lot of memory building internal data structures while performing the CSG.
-Marius
cacb wrote
I thought your case was interesting. It makes little sense that 3GB
memory is required for rendering a surface of less than 300x300 data
points.
Yes. But CGAL uses rationals, I once tried to understand their data
structure, it was scary.
I downloaded your file and tried to replicate your model:
http://arnholm.org/software/as_csg/surface/surface_file.png
As you can see, it renders in 30 seconds in OpenSCAD without any
problems after generating it with AngelScript CSG:
Thanks for that. OpenSCAD F6 of that .csg used ~700KB
OpenSCAD F6 of Anglescript .csg / OpenSCAD F6 of .scad below
Vertices: 7213/153572
Halfedges: 37566/874810
Edges: 18783/437405
Halffacets: 23144/567670
Facets: 11572/283835
h = 30;
r = 30;
e = 3;
union()
{
translate([0,20,-0.5])
rotate([90,0,0])
cylinder(h=h+10, r=r+e, $fn=100);
/*
translate([0,0,15])
rotate(-125, [0,0,1])
translate([0.5,0,0])
rotate(-90, [1,0,0])
rotate(90, [0,1,0])
*/
scale([0.154, 0.109, 1])
surface(file = "model.data", center = true, invert = false);
}
Newly minted Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
View this message in context: http://forum.openscad.org/Changes-to-CGAL-datastructures-Memory-use-tp15531p15561.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On 2016-01-08 02:39, Marius Kintel wrote:
A stand-alone surface() is fast as it’s just a polygon mesh and we
don’t need to touch CGAL. The issues happen when we do CSG ops on it -
we then need to convert it into CGAL data structures, and CGAL
subsequently uses a lot of memory building internal data structures
while performing the CSG.
It was OpenSCAD that performed the CSG boolean operation with CGAL in
both cases, using the exact same surface data file, directly or
indirectly. Same computer (my ~4 year old Win7 desktop), same software
(OpenSCAD 2015.03-2). But the experiences were miles apart.
In the case where AngelScript CSG prepared the .csg file, it took <1 sec
to create the .csg and then OpenSCAD used 30sec to do the boolean
operation with CGAL, consuming approximately 4-500 MB of RAM in the
process. Perhaps reasonable, although I would have liked it to be
faster.
In the case where OpenSCAD read the data file by itself, using the
surface command, the boolean rendering with CGAL took nearly 30 minutes
on my computer, consuming some 3-4GB of RAM in the process, essentially
bringing the computer down on its knees. From the output one can observe
that the number of resulting vertices and facets appear to be at least
an order of magnitude larger in this case.
The difference is that in the AngelScript CSG case, OpenSCAD does not
see the surface data file directly, but instead a ready made polyhedron.
I suspect this polyhedron is much less dense than the equivalent data
structure generated by OpenSCAD, it would explain the difference. The
visual appearances of the end results are similar.
Carsten Arnholm
On Jan 8, 2016, at 02:36 AM, arnholm@arnholm.org wrote:
It was OpenSCAD that performed the CSG boolean operation with CGAL in both cases, using the exact same surface data file, directly or indirectly. Same computer (my ~4 year old Win7 desktop), same software (OpenSCAD 2015.03-2). But the experiences were miles apart.
You forgot a tiny detail: Your polyhedron only contains ca. 1/9th of the pixels from the image.
I didn’t find your code anywhere so I cannot tell what you did wrong, but I guess just just skipped 8 lines from the data file for every line you used.
-Marius
On 08. jan. 2016 22:12, Marius Kintel wrote:
You forgot a tiny detail: Your polyhedron only contains ca. 1/9th of the pixels from the image.
Data reduction is a goal, not a problem as long as the visual
representation is reasonable. However, see below, I did do a mistake and
it did have a visual effect, I just didn't notice well enough.
but I guess just just skipped 8 lines from the data file for every line you used.
No, I just double checked. However I did do something unintended that
had a similar effect, so in a way you are right. I used the (smaller)
default value of the polyhedron segmentation and it has that kind of
reduction effect. The value is independent of the actual number of
points in the data set. Perhaps there should not be a small default
value, I will change it to mean the default uses all points, but still
allowing a smaller value. When I set it to 300 to capture every point,
now I get
http://arnholm.org/software/as_csg/surface/surface_file_full.png
Total rendering time: 0 hours, 9 minutes, 32 seconds
Top level object is a 3D object:
Simple: yes
Vertices: 56047
Halfedges: 327334
Edges: 163667
Halffacets: 215244
Facets: 107622
Volumes: 2
Rendering finished.
So I agree it is more similar. To generate the bigger polyhedron still
takes only 2 seconds.
http://arnholm.org/software/as_csg/surface/surface_file.7z
If I reduce the number of generated polyhedron facets (using the same
parameter) to 150 instead of 300 in one direction, rendering takes 2
minutes 21 seconds instead of 9 minutes and 32 seconds, with very minor
visual degradation.
Thanks for (almost) spotting the cause of the difference.
Carsten Arnholm
cacb wrote
No, I just double checked. However I did do something unintended that
had a similar effect, so in a way you are right. I used the (smaller)
default value of the polyhedron segmentation and it has that kind of
reduction effect. The value is independent of the actual number of
points in the data set. Perhaps there should not be a small default
value, I will change it to mean the default uses all points, but still
allowing a smaller value. When I set it to 300 to capture every point,
now I get
http://arnholm.org/software/as_csg/surface/surface_file_full.png
Total rendering time: 0 hours, 9 minutes, 32 seconds
Top level object is a 3D object:
Simple: yes
Vertices: 56047
Halfedges: 327334
Edges: 163667
Halffacets: 215244
Facets: 107622
Volumes: 2
Rendering finished.
From the look of the .png it has a lower $fn for the cylinder() than the
100 in the original (or mine just above).
Newly minted Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
View this message in context: http://forum.openscad.org/Changes-to-CGAL-datastructures-Memory-use-tp15531p15577.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Carsten,
Just to clarify: There should not be any difference in performance from using a surface() vs. the corresponding polyhedron(). These produce exactly the same internal data structure in OpenSCAD. If you see any differences that’s likely to be differences in the actually produced geometry. …or an unknown bug in OpenSCAD - that happens too :)
-Marius
On 09. jan. 2016 03:44, Marius Kintel wrote:
Carsten,
Just to clarify: There should not be any difference in performance from using a surface() vs. the corresponding polyhedron(). These produce exactly the same internal data structure in OpenSCAD. If you see any differences that’s likely to be differences in the actually produced geometry. …or an unknown bug in OpenSCAD - that happens too :)
-Marius
Thank you, Marius, it makes sense. I have been experimenting a little
with both the OpenSCAD 'surface' command reading images and the
equivalent new feature in AngelScript CSG which creates explicit
polyhedrons http://arnholm.org/angelscript-csg-part-3/
I am able to import images in both cases, but it seems very difficult to
successfully perform any booleans on such models.
Carsten Arnholm