discuss@lists.openscad.org

OpenSCAD general discussion Mailing-list

View all threads

Efficiencies and difficulties of creating files

WF
William F. Adams
Sun, Sep 6, 2020 7:02 PM

If one makes a basic 3D object:
cube(size = [4,9,1], center = false);
then it calculates straight-forwardly enough:
Rendering Polygon Mesh using CGAL...
Geometries in cache: 2
Geometry cache size in bytes: 1456
CGAL Polyhedrons in cache: 0
CGAL cache size in bytes: 0
Total rendering time: 0:00:00.020
   Top level object is a 3D object:
   Facets:          6
but if one makes the same shape using hull operations:
(see screen grab at: https://community.carbide3d.com/t/efficiency-of-stl-generation-in-openscad/25639 )
Rendering Polygon Mesh using CGAL...
Geometries in cache: 11
Geometry cache size in bytes: 154600
CGAL Polyhedrons in cache: 3
CGAL cache size in bytes: 485872
Total rendering time: 0:00:07.088
   Top level object is a 3D object:
   Simple:        yes
   Vertices:        8
   Halfedges:      24
   Edges:          12
   Halffacets:     12
   Facets:          6
   Volumes:         2
which is an increase in some number of 100-fold.
Interestingly if one exports an STL, both files create a 1,535 byte STL file --- presumably there is some optimization which happens when creating the STL.
Would it improve handling of files created using similar techniques to perform this operation intermittently while working on an OpenSCAD file?
Is there some command which would do this already?
William

If one makes a basic 3D object: cube(size = [4,9,1], center = false); then it calculates straight-forwardly enough: Rendering Polygon Mesh using CGAL... Geometries in cache: 2 Geometry cache size in bytes: 1456 CGAL Polyhedrons in cache: 0 CGAL cache size in bytes: 0 Total rendering time: 0:00:00.020    Top level object is a 3D object:    Facets:          6 but if one makes the same shape using hull operations: (see screen grab at: https://community.carbide3d.com/t/efficiency-of-stl-generation-in-openscad/25639 ) Rendering Polygon Mesh using CGAL... Geometries in cache: 11 Geometry cache size in bytes: 154600 CGAL Polyhedrons in cache: 3 CGAL cache size in bytes: 485872 Total rendering time: 0:00:07.088    Top level object is a 3D object:    Simple:        yes    Vertices:        8    Halfedges:      24    Edges:          12    Halffacets:     12    Facets:          6    Volumes:         2 which is an increase in some number of 100-fold. Interestingly if one exports an STL, both files create a 1,535 byte STL file --- presumably there is some optimization which happens when creating the STL. Would it improve handling of files created using similar techniques to perform this operation intermittently while working on an OpenSCAD file? Is there some command which would do this already? William
TP
Torsten Paul
Sun, Sep 6, 2020 7:57 PM

On 06.09.20 21:02, William F. Adams via Discuss wrote:

which is an increase in some number of 100-fold.

Just as you commanded by giving $fn = 80.

Would it improve handling of files created using
similar techniques to perform this operation intermittently
while working on an OpenSCAD file?

What does that mean?

ciao,
Torsten.

On 06.09.20 21:02, William F. Adams via Discuss wrote: > which is an increase in some number of 100-fold. Just as you commanded by giving $fn = 80. > Would it improve handling of files created using > similar techniques to perform this operation intermittently > while working on an OpenSCAD file? What does that mean? ciao, Torsten.
CA
Carsten Arnholm
Sun, Sep 6, 2020 8:00 PM

On 06.09.2020 21:02, William F. Adams via Discuss wrote:

which is an increase in some number of 100-fold.

Interestingly if one exports an STL, both files create a 1,535 byte STL
file --- presumably there is some optimization which happens when
creating the STL.

What you are observing is that the first example is a primitive solid,
no need to involve CGAL booleans in order to create an STL from it.

The second example uses union, hull and difference on multiple solid
primitives, "accidentally" ending up with a result equivalent to the
first primitive solid, in OpenSCAD this means using CGAL datastructures
and operations. What is listed for the second case is resulting CGAL
half edge datastructure object counts for the resulting cuboid-shaped
polyhedron. Translated to STL it gives the same result as in the
primitive case.

There is no optimization happening related to STL, you just devised two
very different routes to creating the same object, where one route is
much more complex than the other.

The 100-fold increase in cache size could perhaps be taken as a measure
of how much more complex the second route is. It does not say anything
about the complexity of the result.

Of course, if you could save intermediate objects to file and forget
about how complex the route was to get there, potentially you could
solve larger problems.

Regards
Carsten Arholm

On 06.09.2020 21:02, William F. Adams via Discuss wrote: > which is an increase in some number of 100-fold. > > Interestingly if one exports an STL, both files create a 1,535 byte STL > file --- presumably there is some optimization which happens when > creating the STL. What you are observing is that the first example is a primitive solid, no need to involve CGAL booleans in order to create an STL from it. The second example uses union, hull and difference on multiple solid primitives, "accidentally" ending up with a result equivalent to the first primitive solid, in OpenSCAD this means using CGAL datastructures and operations. What is listed for the second case is resulting CGAL half edge datastructure object counts for the resulting cuboid-shaped polyhedron. Translated to STL it gives the same result as in the primitive case. There is no optimization happening related to STL, you just devised two very different routes to creating the same object, where one route is much more complex than the other. The 100-fold increase in cache size could perhaps be taken as a measure of how much more complex the second route is. It does not say anything about the complexity of the result. Of course, if you could save intermediate objects to file and forget about how complex the route was to get there, potentially you could solve larger problems. Regards Carsten Arholm
WF
William F. Adams
Sun, Sep 6, 2020 8:16 PM

Carsten Arnholm wrote:

There is no optimization happening related to STL, you just devised two
very different routes to creating the same object, where one route is
much more complex than the other.

Oh.

The 100-fold increase in cache size could perhaps be taken as a measure
of how much more complex the second route is. It does not say anything
about the complexity of the result.

Okay. But what about the complexity of the internal representation?

Of course, if you could save intermediate objects to file and forget
about how complex the route was to get there, potentially you could
solve larger problems.

Agreed, but I'd rather not trouble about writing out a file --- would it be feasible/desirable to afford a command in OpenSCAD which would do this sort of internal optimization with an eye towards allowing OpenSCAD to work faster and to allow working on more complex files?
William 

Carsten Arnholm wrote: >There is no optimization happening related to STL, you just devised two >very different routes to creating the same object, where one route is >much more complex than the other. Oh. >The 100-fold increase in cache size could perhaps be taken as a measure >of how much more complex the second route is. It does not say anything >about the complexity of the result. Okay. But what about the complexity of the internal representation? >Of course, if you could save intermediate objects to file and forget >about how complex the route was to get there, potentially you could >solve larger problems. Agreed, but I'd rather not trouble about writing out a file --- would it be feasible/desirable to afford a command in OpenSCAD which would do this sort of internal optimization with an eye towards allowing OpenSCAD to work faster and to allow working on more complex files? William 
D
David
Sun, Sep 6, 2020 8:31 PM

That sounds interesting.

On 9/6/20 3:16 PM, William F. Adams via Discuss wrote:

Carsten Arnholm wrote:

There is no optimization happening related to STL, you just devised two
very different routes to creating the same object, where one route is
much more complex than the other.

Oh.

The 100-fold increase in cache size could perhaps be taken as a measure
of how much more complex the second route is. It does not say anything
about the complexity of the result.

Okay. But what about the complexity of the internal representation?

Of course, if you could save intermediate objects to file and forget
about how complex the route was to get there, potentially you could
solve larger problems.

Agreed, but I'd rather not trouble about writing out a file --- would
it be feasible/desirable to afford a command in OpenSCAD which would
do this sort of internal optimization with an eye towards allowing
OpenSCAD to work faster and to allow working on more complex files?

William


OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

That sounds interesting. On 9/6/20 3:16 PM, William F. Adams via Discuss wrote: > Carsten Arnholm wrote: > > >There is no optimization happening related to STL, you just devised two > >very different routes to creating the same object, where one route is > >much more complex than the other. > > Oh. > > >The 100-fold increase in cache size could perhaps be taken as a measure > >of how much more complex the second route is. It does not say anything > >about the complexity of the result. > > Okay. But what about the complexity of the internal representation? > > >Of course, if you could save intermediate objects to file and forget > >about how complex the route was to get there, potentially you could > >solve larger problems. > > Agreed, but I'd rather not trouble about writing out a file --- would > it be feasible/desirable to afford a command in OpenSCAD which would > do this sort of internal optimization with an eye towards allowing > OpenSCAD to work faster and to allow working on more complex files? > > William > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
WF
William F. Adams
Sun, Sep 6, 2020 8:56 PM

On 06.09.20 21:02, William F. Adams via Discuss wrote:

which is an increase in some number of 100-fold.

and Torsten Paul replied:

Just as you commanded by giving $fn = 80.

but if I comment that out we still get:
Rendering Polygon Mesh using CGAL...Geometries in cache: 11Geometry cache size in bytes: 13048CGAL Polyhedrons in cache: 3CGAL cache size in bytes: 77296Total rendering time: 0:00:00.724 Top level object is a 3D object: Simple: yes Vertices: 8 Halfedges: 24 Edges: 12 Halffacets: 12 Facets: 6 Volumes: 2Rendering finished.
which still has some markedly larger numbers.

Would it improve handling of files created using
similar techniques to perform this operation intermittently
while working on an OpenSCAD file?

What does that mean?

What if there were a command which would allow when possible simplifying the geometric representation to a simpler form involving fewer triangles?
Presumably if the basic cube and the hulled version had further operations applied to them the hulled version would be more complex in internal representation than the same operation applied to the basic cube.
If there were such a simplification process command it could be called after complex operations (with simple results?) and then simpler, more elegant (in the traditional sense of "scientifically correct") representation be used for further operations.
William

On 06.09.20 21:02, William F. Adams via Discuss wrote: >> which is an increase in some number of 100-fold. and Torsten Paul replied: >Just as you commanded by giving $fn = 80. but if I comment that out we still get: Rendering Polygon Mesh using CGAL...Geometries in cache: 11Geometry cache size in bytes: 13048CGAL Polyhedrons in cache: 3CGAL cache size in bytes: 77296Total rendering time: 0:00:00.724 Top level object is a 3D object: Simple: yes Vertices: 8 Halfedges: 24 Edges: 12 Halffacets: 12 Facets: 6 Volumes: 2Rendering finished. which still has some markedly larger numbers. >> Would it improve handling of files created using >> similar techniques to perform this operation intermittently >> while working on an OpenSCAD file? >What does that mean? What if there were a command which would allow when possible simplifying the geometric representation to a simpler form involving fewer triangles? Presumably if the basic cube and the hulled version had further operations applied to them the hulled version would be more complex in internal representation than the same operation applied to the basic cube. If there were such a simplification process command it could be called after complex operations (with simple results?) and then simpler, more elegant (in the traditional sense of "scientifically correct") representation be used for further operations. William
CA
Carsten Arnholm
Sun, Sep 6, 2020 9:11 PM

On 06.09.2020 22:16, William F. Adams via Discuss wrote:

Carsten Arnholm wrote:

Of course, if you could save intermediate objects to file and forget
about how complex the route was to get there, potentially you could
solve larger problems.

Agreed, but I'd rather not trouble about writing out a file --- would it
be feasible/desirable to afford a command in OpenSCAD which would do
this sort of internal optimization with an eye towards allowing OpenSCAD
to work faster and to allow working on more complex files?

In theory, perhaps. This would be something for the OpenSCAD developers
to answer. My guess is it is not so easy.

Carsten Arnholm

On 06.09.2020 22:16, William F. Adams via Discuss wrote: > Carsten Arnholm wrote: > >Of course, if you could save intermediate objects to file and forget > >about how complex the route was to get there, potentially you could > >solve larger problems. > > Agreed, but I'd rather not trouble about writing out a file --- would it > be feasible/desirable to afford a command in OpenSCAD which would do > this sort of internal optimization with an eye towards allowing OpenSCAD > to work faster and to allow working on more complex files? In theory, perhaps. This would be something for the OpenSCAD developers to answer. My guess is it is not so easy. Carsten Arnholm
TP
Torsten Paul
Sun, Sep 6, 2020 9:14 PM

On 06.09.20 22:56, William F. Adams via Discuss wrote:

Just as you commanded by giving $fn = 80.

but if I comment that out we still get:

Yes, it's still using the default resolution for the
hulled cylinders which have more vertices than just a
plain cube.

What if there were a command which would allow when
possible simplifying the geometric representation to
a simpler form involving fewer triangles?

That might be useful, but could prove a bit difficult
to parameterize (e.g. limit by face angle, and such
things).

In addition to that, there's an almost finished change
implementing a persistent cache. Hopefully that will
get to mergeable state soon-ish. In combination with
render() that would allow to cover cases where people
did export partial models as STL before.

ciao,
Torsten.

On 06.09.20 22:56, William F. Adams via Discuss wrote: >>Just as you commanded by giving $fn = 80. > but if I comment that out we still get: Yes, it's still using the default resolution for the hulled cylinders which have more vertices than just a plain cube. > What if there were a command which would allow when > possible simplifying the geometric representation to > a simpler form involving fewer triangles? That might be useful, but could prove a bit difficult to parameterize (e.g. limit by face angle, and such things). In addition to that, there's an almost finished change implementing a persistent cache. Hopefully that will get to mergeable state soon-ish. In combination with render() that would allow to cover cases where people did export partial models as STL before. ciao, Torsten.
M
MichaelAtOz
Sun, Sep 6, 2020 11:07 PM

You should examine the Design/Display-[CSG Tree / CSG Products] for your
milled version.
You will see the complexity it produces.


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/

You should examine the Design/Display-[CSG Tree / CSG Products] for your milled version. You will see the complexity it produces. ----- 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/
T
Troberg
Mon, Sep 7, 2020 10:06 AM

OpenSCAD mailing list-2 wrote

What if there were a command which would allow when possible simplifying
the geometric representation to a simpler form involving fewer triangles?

Such as render()?

Try activating "show edges" and look at the difference between and after a
render() of your objects.

--
Sent from: http://forum.openscad.org/

OpenSCAD mailing list-2 wrote > What if there were a command which would allow when possible simplifying > the geometric representation to a simpler form involving fewer triangles? Such as render()? Try activating "show edges" and look at the difference between and after a render() of your objects. -- Sent from: http://forum.openscad.org/