Slow rendering performance and high memory consumption when exporting a 3D STL
I think the reason CGAL is slow and uses a huge amount of memory is the
fact it uses a rational number representation but any model with curves or
rotations has irrational coordinates, so the fractions must become huge as
the denominator tends towards infinity.
On Fri, 14 Aug 2020 at 10:01, arnholm@arnholm.org wrote:
On 2020-08-14 10:13, peter_osc@xs4all.nl wrote:
What I still don't understand too is why this relatively simple
problem peaks at 5 gigabytes.
Your compared it with AngelCAD. I also did a comparison with FreeCAD
(OpenCascade) where this problem was also solved in a matter of
seconds instead of hours. I even compared both resulting STLs but
couldn't find any fundamental differences, except that the faceting in
FreeCAD looks a bit different and has more faces. I included the
FreeCAD Script.
For so far now the rendering for an STL benchmark results are:
FreeCAD: 1 second
AngelCAD: < 10 seconds
OpenSCAD: about 1 hour (depending on computer speed)
I don't know FreeCAD to any detail, but I know it is based on
OpenCascade. I happened to work for a while using CAS.CADE many moons
ago, well before it became OpenCascade. OpenCascade is a totally
different data model compared to CGAL, or at least how CGAL is used in
OpenSCAD.
In OpenCascade you have geometry decoupled from topology and faces and
edges can have complex geometries. A sphere is not a collection of
facets, but most likely a few faces with a shared, explicit spherical
geometry specification. Only when exporting to STL you get flat
triangular facets. Computing intersections between planes and spheres in
OpenCascade is much more exact and fast compared to surface mesh based
systems like OpenSCAD and AngelCAD. But this comes at the cost of a much
larger and complex library and data structure.
FreeCAD/OpenCascade is based on a BREP data structure, like most
traditional CAD systems. Other libraries like ACIS fall in the same
category (I used to work a lot with ACIS). These are not based on
surface mesh data structures. Coordinates are ordinary floating point
values. I don't know if FreeCAD uses multi-treading for calculations.
OpenSCAD is based on a surface mesh data structure, implemented using
the CGAL library and using "fractional numbers" for coordinate
representation and calculations. The CGAL data structure and fractional
number representation come at a huge cost in performance and memory
requirements for non-trivial models, but promises high precision in
calculations. Given that input is floating point numbers and an
imprecise mesh representation is used anyway, it could be argued that
the return on the "memory/processor investment" is at best low. I
believe the official version of OpenSCAD is single threaded (I could be
wrong), but I know experiments have been done on multi-treading for
boolean operations in order to speed things up.
AngelCAD/xcsg is based on a surface mesh data structure, xcsg is
implemented using the CARVE library and using ordinary floating point
numbers for coordinates. CARVE has a much more light-weight mesh data
structure and is very fast, but has some rough edges sometimes. xcsg
uses multi-threading for all boolean operations, which speeds up things
a lot.
So the timings you are seeing is very much functions of the data
structures, number representation and libraries used, plus whether
multi-threading is applied. The use of fractional numbers in OpenSCAD
slows things down and is probably the main reason for the very high
memory footprint observed, and the high memory footprint is itself a
reason for slower performance.
Regards
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Not to mention the number of hard page faults this will generate on systems with limited physical memory, further slowing down performance.
From: Discuss discuss-bounces@lists.openscad.org On Behalf Of nop head
Sent: Friday, August 14, 2020 11:59
To: OpenSCAD general discussion discuss@lists.openscad.org
Subject: Re: [OpenSCAD] Slow rendering performance and high memory consumption when exporting a 3D STL
I think the reason CGAL is slow and uses a huge amount of memory is the fact it uses a rational number representation but any model with curves or rotations has irrational coordinates, so the fractions must become huge as the denominator tends towards infinity.
On Fri, 14 Aug 2020 at 10:01, <arnholm@arnholm.org mailto:arnholm@arnholm.org > wrote:
On 2020-08-14 10:13, peter_osc@xs4all.nl mailto:peter_osc@xs4all.nl wrote:
What I still don't understand too is why this relatively simple
problem peaks at 5 gigabytes.
Your compared it with AngelCAD. I also did a comparison with FreeCAD
(OpenCascade) where this problem was also solved in a matter of
seconds instead of hours. I even compared both resulting STLs but
couldn't find any fundamental differences, except that the faceting in
FreeCAD looks a bit different and has more faces. I included the
FreeCAD Script.
For so far now the rendering for an STL benchmark results are:
FreeCAD: 1 second
AngelCAD: < 10 seconds
OpenSCAD: about 1 hour (depending on computer speed)
I don't know FreeCAD to any detail, but I know it is based on
OpenCascade. I happened to work for a while using CAS.CADE many moons
ago, well before it became OpenCascade. OpenCascade is a totally
different data model compared to CGAL, or at least how CGAL is used in
OpenSCAD.
In OpenCascade you have geometry decoupled from topology and faces and
edges can have complex geometries. A sphere is not a collection of
facets, but most likely a few faces with a shared, explicit spherical
geometry specification. Only when exporting to STL you get flat
triangular facets. Computing intersections between planes and spheres in
OpenCascade is much more exact and fast compared to surface mesh based
systems like OpenSCAD and AngelCAD. But this comes at the cost of a much
larger and complex library and data structure.
FreeCAD/OpenCascade is based on a BREP data structure, like most
traditional CAD systems. Other libraries like ACIS fall in the same
category (I used to work a lot with ACIS). These are not based on
surface mesh data structures. Coordinates are ordinary floating point
values. I don't know if FreeCAD uses multi-treading for calculations.
OpenSCAD is based on a surface mesh data structure, implemented using
the CGAL library and using "fractional numbers" for coordinate
representation and calculations. The CGAL data structure and fractional
number representation come at a huge cost in performance and memory
requirements for non-trivial models, but promises high precision in
calculations. Given that input is floating point numbers and an
imprecise mesh representation is used anyway, it could be argued that
the return on the "memory/processor investment" is at best low. I
believe the official version of OpenSCAD is single threaded (I could be
wrong), but I know experiments have been done on multi-treading for
boolean operations in order to speed things up.
AngelCAD/xcsg is based on a surface mesh data structure, xcsg is
implemented using the CARVE library and using ordinary floating point
numbers for coordinates. CARVE has a much more light-weight mesh data
structure and is very fast, but has some rough edges sometimes. xcsg
uses multi-threading for all boolean operations, which speeds up things
a lot.
So the timings you are seeing is very much functions of the data
structures, number representation and libraries used, plus whether
multi-threading is applied. The use of fractional numbers in OpenSCAD
slows things down and is probably the main reason for the very high
memory footprint observed, and the high memory footprint is itself a
reason for slower performance.
Regards
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org mailto:Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Thanks for the insight.
Given the inaccuracy of all other (engineering) models I use, and the uncertainty bandwidth for input parameters, an accuracy of 0.1 to 1% is acceptable for me. A factor of 100 to 1000 performance decrease is a too high price for the sake of accuracy that I probably don’t need.
But that raises the question: can CGAL be configured that it offers better performance at the cost of decreased accuracy, or is it always accurate by design?
Pete.
From: Discuss discuss-bounces@lists.openscad.org On Behalf Of peter_osc@xs4all.nl
Sent: Friday, August 14, 2020 13:33
To: 'OpenSCAD general discussion' discuss@lists.openscad.org
Subject: Re: [OpenSCAD] Slow rendering performance and high memory consumption when exporting a 3D STL
Not to mention the number of hard page faults this will generate on systems with limited physical memory, further slowing down performance.
From: Discuss <discuss-bounces@lists.openscad.org mailto:discuss-bounces@lists.openscad.org > On Behalf Of nop head
Sent: Friday, August 14, 2020 11:59
To: OpenSCAD general discussion <discuss@lists.openscad.org mailto:discuss@lists.openscad.org >
Subject: Re: [OpenSCAD] Slow rendering performance and high memory consumption when exporting a 3D STL
I think the reason CGAL is slow and uses a huge amount of memory is the fact it uses a rational number representation but any model with curves or rotations has irrational coordinates, so the fractions must become huge as the denominator tends towards infinity.
On Fri, 14 Aug 2020 at 10:01, <arnholm@arnholm.org mailto:arnholm@arnholm.org > wrote:
On 2020-08-14 10:13, peter_osc@xs4all.nl mailto:peter_osc@xs4all.nl wrote:
What I still don't understand too is why this relatively simple
problem peaks at 5 gigabytes.
Your compared it with AngelCAD. I also did a comparison with FreeCAD
(OpenCascade) where this problem was also solved in a matter of
seconds instead of hours. I even compared both resulting STLs but
couldn't find any fundamental differences, except that the faceting in
FreeCAD looks a bit different and has more faces. I included the
FreeCAD Script.
For so far now the rendering for an STL benchmark results are:
FreeCAD: 1 second
AngelCAD: < 10 seconds
OpenSCAD: about 1 hour (depending on computer speed)
I don't know FreeCAD to any detail, but I know it is based on
OpenCascade. I happened to work for a while using CAS.CADE many moons
ago, well before it became OpenCascade. OpenCascade is a totally
different data model compared to CGAL, or at least how CGAL is used in
OpenSCAD.
In OpenCascade you have geometry decoupled from topology and faces and
edges can have complex geometries. A sphere is not a collection of
facets, but most likely a few faces with a shared, explicit spherical
geometry specification. Only when exporting to STL you get flat
triangular facets. Computing intersections between planes and spheres in
OpenCascade is much more exact and fast compared to surface mesh based
systems like OpenSCAD and AngelCAD. But this comes at the cost of a much
larger and complex library and data structure.
FreeCAD/OpenCascade is based on a BREP data structure, like most
traditional CAD systems. Other libraries like ACIS fall in the same
category (I used to work a lot with ACIS). These are not based on
surface mesh data structures. Coordinates are ordinary floating point
values. I don't know if FreeCAD uses multi-treading for calculations.
OpenSCAD is based on a surface mesh data structure, implemented using
the CGAL library and using "fractional numbers" for coordinate
representation and calculations. The CGAL data structure and fractional
number representation come at a huge cost in performance and memory
requirements for non-trivial models, but promises high precision in
calculations. Given that input is floating point numbers and an
imprecise mesh representation is used anyway, it could be argued that
the return on the "memory/processor investment" is at best low. I
believe the official version of OpenSCAD is single threaded (I could be
wrong), but I know experiments have been done on multi-treading for
boolean operations in order to speed things up.
AngelCAD/xcsg is based on a surface mesh data structure, xcsg is
implemented using the CARVE library and using ordinary floating point
numbers for coordinates. CARVE has a much more light-weight mesh data
structure and is very fast, but has some rough edges sometimes. xcsg
uses multi-threading for all boolean operations, which speeds up things
a lot.
So the timings you are seeing is very much functions of the data
structures, number representation and libraries used, plus whether
multi-threading is applied. The use of fractional numbers in OpenSCAD
slows things down and is probably the main reason for the very high
memory footprint observed, and the high memory footprint is itself a
reason for slower performance.
Regards
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org mailto:Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Just some last notes about this issue.
Yesterday I fired up OpenSCAD with the full design and tried to render (F6) a cuboid intersection which should yield a slice of 50mm thick slice of the design.
The design contains about 7000 objects, mainly (differences and unions) of cylinders, cones and spheres. No Minkowski sums, extrudes or whatsoever.
After about 20 hours while OpenSCAD was still rendering this intersection, it using 60 Gigabytes of memory. Windows then generated a fatal error for OpenSCAD.
From that moment I even could not start any other applications (like Word or Paint) to save a screendump of the error message and the status of SysInternals. The system finally froze with a black screen and I had to reboot. I guess the system was completely out of resources.
Summarizing: the GUI was stable (though notably slower) with this complex design and I was capable to calculate and visualize the intersection in the GUI. However it was impossible to render (F6) the intersection so that I could export the corresponding STL output for further processing.
For most users this won’t a problem though.
I’m open to future suggestions and will keep an eye on this thread. Maybe this can be done with CGAL only in a different configuration.
Pete.
Peter O. wrote
The system finally froze with a black screen and I had to reboot. I guess
the system was completely out of resources.
I've had that. Windows is not the best memory manager.
Sometimes you can close other apps, to free memory, let the system recover.
Summarizing: the GUI was stable (though notably slower) with this complex
design and I was capable to calculate and visualize the intersection in
the GUI. However it was impossible to render (F6) the intersection so that
I could export the corresponding STL output for further processing.
I’m open to future suggestions and will keep an eye on this thread. Maybe
this can be done with CGAL only in a different configuration.
You have to reduce the number of faces.
Reduce $fn etc.
If the layout is like the images above, if you can exclude building those
spheres which are clearly outside the cuboid, that would reduce faces & CGAL
processing & memory.
Get more memory and/or bigger swap files on a fast SSD.
OpenSCAD Admin - email* me if you need anything, or if I've done something stupid...
- on the Forum, click on my MichaelAtOz label, there is a link to email me.
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.
--
Sent from: http://forum.openscad.org/