In search for the limits of CGAL

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

In search for the limits of CGAL

peter_osc

I recently posted a message in the OpenSCAD forum about slow performance on rendering.

http://forum.openscad.org/Slow-rendering-performance-and-high-memory-consumption-when-exporting-a-3D-STL-td29888.html

 

The problem is this: we use machine generated designs that might have up to 7,000 elements. At any time we want to make intersections of this design, effectively dividing it up into 20 to 100 slices of which we must gather properties like volume, centroid and inertia tensors. We use a post processor to add material properties as CGAL (and all other geometric engines) don’t know any material properties.

 

We thought this could be done by creating meshes (STL) from these intersection/slices in OpenSCAD but found out that OpenSCAD couldn’t do this. It uses memory up to 50+ GB and more and finally the system freezes due to a lack of resources. OpenSCAD community members suggested that this might be caused by the fact that CGAL uses fractional numbers for its (final?) rendering. In the OpenSCAD GUI, it still manages to calculate and render the intersection within a second but fails to do the final rendering prior to exporting the STL. So it seems there are two rendering strategies active at the same time: ‘quick’ and ‘slow but accurate’.

 

I also defined a benchmark in the above post where an intersection is to be calculated between a cuboid and a stacked series of rings that contain spheres. It turned out that OpenSCAD using the CGAL engine managed to do this in 42 minutes using 5GB of memory while two other packages (FreeCAD and AngelCad based on OpenCascade and CARVE respectively) managed to do this in a few seconds or even less. So there is a factor of 100 performance difference between CGAL and the rest which I consider as huge.

 

I therefore want to ask the experts for their opinion and guidance:

  • Is this slow performance  and huge memory consumption for rendering an intersection of a complex design in OpenSCAD actually caused by CGAL because it uses fractional numbers as some community members suggested?
  • Are there any workarounds in CGAL itself (assuming that we would directly communicate with the geometric engine instead of using OpenSCAD) where we would be able to make meshes (STLs) from intersection of complex (3000+ elements) designs?
  • Are there any possibilities in CGAL to directly ask for properties of an intersection like the volume and centroid without creating a mesh?

 

 

Your advice is greatly appreciated,

Pete


--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss

Reply | Threaded
Open this post in threaded view
|

Re: In search for the limits of CGAL

andreas.fabri

Hello,

We have no idea how OpenSCAD uses CGAL.

What do you mean with " intersection of complex (3000+ elements) designs:"?

Maybe you can give us some example data sets and we can tell you how to do
Boolean operations.  Note that CGAL Boolean operations work for volumes
given as triangle meshes, so in case you have spheres they have to be
discretized by you.

Best regards,

Andreas

On 8/21/2020 8:52 PM, [hidden email] wrote:

I recently posted a message in the OpenSCAD forum about slow performance on rendering.

http://forum.openscad.org/Slow-rendering-performance-and-high-memory-consumption-when-exporting-a-3D-STL-td29888.html

 

The problem is this: we use machine generated designs that might have up to 7,000 elements. At any time we want to make intersections of this design, effectively dividing it up into 20 to 100 slices of which we must gather properties like volume, centroid and inertia tensors. We use a post processor to add material properties as CGAL (and all other geometric engines) don’t know any material properties.

 

We thought this could be done by creating meshes (STL) from these intersection/slices in OpenSCAD but found out that OpenSCAD couldn’t do this. It uses memory up to 50+ GB and more and finally the system freezes due to a lack of resources. OpenSCAD community members suggested that this might be caused by the fact that CGAL uses fractional numbers for its (final?) rendering. In the OpenSCAD GUI, it still manages to calculate and render the intersection within a second but fails to do the final rendering prior to exporting the STL. So it seems there are two rendering strategies active at the same time: ‘quick’ and ‘slow but accurate’.

 

I also defined a benchmark in the above post where an intersection is to be calculated between a cuboid and a stacked series of rings that contain spheres. It turned out that OpenSCAD using the CGAL engine managed to do this in 42 minutes using 5GB of memory while two other packages (FreeCAD and AngelCad based on OpenCascade and CARVE respectively) managed to do this in a few seconds or even less. So there is a factor of 100 performance difference between CGAL and the rest which I consider as huge.

 

I therefore want to ask the experts for their opinion and guidance:

  • Is this slow performance  and huge memory consumption for rendering an intersection of a complex design in OpenSCAD actually caused by CGAL because it uses fractional numbers as some community members suggested?
  • Are there any workarounds in CGAL itself (assuming that we would directly communicate with the geometric engine instead of using OpenSCAD) where we would be able to make meshes (STLs) from intersection of complex (3000+ elements) designs?
  • Are there any possibilities in CGAL to directly ask for properties of an intersection like the volume and centroid without creating a mesh?

 

 

Your advice is greatly appreciated,

Pete


--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss

-- 
Andreas Fabri, PhD
Chief Officer, GeometryFactory
Editor, The CGAL Project

phone: +33.492.954.912    skype: andreas.fabri

--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss

Reply | Threaded
Open this post in threaded view
|

Re: In search for the limits of CGAL

Sebastien Loriot (GeometryFactory)
In reply to this post by peter_osc
Hi,

OpenSCAD is using the Nef_3 packages that is known to have a big
runtime overhead to handle all possible geometries.
The more recent Polygon Mesh Processing corefinement code which is
restricted to operation on triangle mesh is much faster and should be
used whenever it is possible.

I already proposed to Marius Kintel to have a joint workshop/hackaton to
discuss (and implement) among other things a possible replacement but
with his new position Marius is quite busy. If they are other
contributors of OpenSCAD that knows well enough the code, I'm still
willing to work with them to improve things.

Best regards,

Sebastien.

On 8/21/20 8:52 PM, [hidden email] wrote:

> I recently posted a message in the OpenSCAD forum about slow performance
> on rendering.
>
> http://forum.openscad.org/Slow-rendering-performance-and-high-memory-consumption-when-exporting-a-3D-STL-td29888.html
>
> The problem is this: we use machine generated designs that might have up
> to 7,000 elements. At any time we want to make intersections of this
> design, effectively dividing it up into 20 to 100 slices of which we
> must gather properties like volume, centroid and inertia tensors. We use
> a post processor to add material properties as CGAL (and all other
> geometric engines) don’t know any material properties.
>
> We thought this could be done by creating meshes (STL) from these
> intersection/slices in OpenSCAD but found out that OpenSCAD couldn’t do
> this. It uses memory up to 50+ GB and more and finally the system
> freezes due to a lack of resources. OpenSCAD community members suggested
> that this might be caused by the fact that CGAL uses fractional numbers
> for its (final?) rendering. In the OpenSCAD GUI, it still manages to
> calculate and render the intersection within a second but fails to do
> the final rendering prior to exporting the STL. So it seems there are
> two rendering strategies active at the same time: ‘quick’ and ‘slow but
> accurate’.
>
> I also defined a benchmark in the above post where an intersection is to
> be calculated between a cuboid and a stacked series of rings that
> contain spheres. It turned out that OpenSCAD using the CGAL engine
> managed to do this in 42 minutes using 5GB of memory while two other
> packages (FreeCAD and AngelCad based on OpenCascade and CARVE
> respectively) managed to do this in a few seconds or even less. So there
> is a factor of 100 performance difference between CGAL and the rest
> which I consider as huge.
>
> I therefore want to ask the experts for their opinion and guidance:
>
>   * Is this slow performance  and huge memory consumption for rendering
>     an intersection of a complex design in OpenSCAD actually caused by
>     CGAL because it uses fractional numbers as some community members
>     suggested?
>   * Are there any workarounds in CGAL itself (assuming that we would
>     directly communicate with the geometric engine instead of using
>     OpenSCAD) where we would be able to make meshes (STLs) from
>     intersection of complex (3000+ elements) designs?
>   * Are there any possibilities in CGAL to directly ask for properties
>     of an intersection like the volume and centroid without creating a mesh?
>
> Your advice is greatly appreciated,
>
> Pete
>
>
> --
> You are currently subscribed to cgal-discuss.
> To unsubscribe or access the archives, go to
> https://sympa.inria.fr/sympa/info/cgal-discuss
>

--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss


Reply | Threaded
Open this post in threaded view
|

RE: In search for the limits of CGAL

peter_osc
In reply to this post by andreas.fabri

Hi Andreas,

 

The link I added in my description contains a benchmark example.

 

The design itself consists of (intersections of) mainly cylinders, cones and spheres.

 

With "intersection of complex (3000+ elements) designs" I mean that I must make cuboid intersections of the design, effectively dividing it into slices. For every slice I must calculate some fundamental properties like mass, volume, area, centroid and inertia tensors.

 

Pete.

 

From: [hidden email] <[hidden email]> On Behalf Of Andreas Fabri
Sent: Sunday, August 23, 2020 18:02
To: [hidden email]
Subject: Re: [cgal-discuss] In search for the limits of CGAL

 

Hello,

We have no idea how OpenSCAD uses CGAL.

What do you mean with " intersection of complex (3000+ elements) designs:"?

Maybe you can give us some example data sets and we can tell you how to do
Boolean operations.  Note that CGAL Boolean operations work for volumes
given as triangle meshes, so in case you have spheres they have to be
discretized by you.

Best regards,

Andreas

On 8/21/2020 8:52 PM, [hidden email] wrote:

I recently posted a message in the OpenSCAD forum about slow performance on rendering.

http://forum.openscad.org/Slow-rendering-performance-and-high-memory-consumption-when-exporting-a-3D-STL-td29888.html

 

The problem is this: we use machine generated designs that might have up to 7,000 elements. At any time we want to make intersections of this design, effectively dividing it up into 20 to 100 slices of which we must gather properties like volume, centroid and inertia tensors. We use a post processor to add material properties as CGAL (and all other geometric engines) don’t know any material properties.

 

We thought this could be done by creating meshes (STL) from these intersection/slices in OpenSCAD but found out that OpenSCAD couldn’t do this. It uses memory up to 50+ GB and more and finally the system freezes due to a lack of resources. OpenSCAD community members suggested that this might be caused by the fact that CGAL uses fractional numbers for its (final?) rendering. In the OpenSCAD GUI, it still manages to calculate and render the intersection within a second but fails to do the final rendering prior to exporting the STL. So it seems there are two rendering strategies active at the same time: ‘quick’ and ‘slow but accurate’.

 

I also defined a benchmark in the above post where an intersection is to be calculated between a cuboid and a stacked series of rings that contain spheres. It turned out that OpenSCAD using the CGAL engine managed to do this in 42 minutes using 5GB of memory while two other packages (FreeCAD and AngelCad based on OpenCascade and CARVE respectively) managed to do this in a few seconds or even less. So there is a factor of 100 performance difference between CGAL and the rest which I consider as huge.

 

I therefore want to ask the experts for their opinion and guidance:

  • Is this slow performance  and huge memory consumption for rendering an intersection of a complex design in OpenSCAD actually caused by CGAL because it uses fractional numbers as some community members suggested?
  • Are there any workarounds in CGAL itself (assuming that we would directly communicate with the geometric engine instead of using OpenSCAD) where we would be able to make meshes (STLs) from intersection of complex (3000+ elements) designs?
  • Are there any possibilities in CGAL to directly ask for properties of an intersection like the volume and centroid without creating a mesh?

 

 

Your advice is greatly appreciated,

Pete


--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss

-- 
Andreas Fabri, PhD
Chief Officer, GeometryFactory
Editor, The CGAL Project
 
phone: +33.492.954.912    skype: andreas.fabri


--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss


--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss