Efficiency of Geometry generation in OpenSCAD

Curious about what happens with OpenSCAD as it renders CSG geometry and STLs. Here we export the same cube:

modeled in various ways and export STLs and compare the log values as a representation of the complexity of the internal mesh.

The most basic example:

cube(size = [4,9,1], center = false);

which the log reports as:

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

If we create a file which creates the same rectangle using a hull operation:

Then we have:

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 for some numbers is an increase 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.

is it an ascii or binary stl file ?

if binary

1535 - 84 (header) = 1451
1451 / 50 (size of facet) = 29

weird number so more likely an ascii stl of sorts?

Good question — it’s the default for exporting from OpenSCAD.

Docs claim support for both:


but doesn’t specify which is the default.

Files begin with:

solid OpenSCAD_Model
  facet normal 0 -1 0
    outer loop
      vertex 0 0 0
      vertex 4 0 1
      vertex 0 0 1

So I’m going to agree w/ your surmise that it’s ASCII.

OpenSCAD does basically no work in the first example because you tell it exactly what you want, a cube. All it has to do is this, which is a constant-time operation which requires nothing in memory other than a cube.

In the second example you’re asking it to do a ton of work. It’s no longer just building a sphere but instead it has to create a bunch of cylinders, find the 3D convex hull for pairs of them, union them and then difference them. There’s no longer just the 8 vertices of a cube to keep in memory (those numbers with 100x multipliers are the cache, so I assume concerned with memory used during calculation rather than anything to do with the output) but all the cylinders and convex hulls you use along the way.

Is that what you were wondering about?

What I’m wondering is if OpenSCAD can be more efficient about this sort of thing.

If there was a command which would simplify internal geometric representation then on-going work could be more efficient.

I think OpenSCAD can only be as efficient as you ask it to be.

There’s a very easy improvement you could make: instead of using hull in your endmillcut module, union the two cylinders with a rectangular prism. The result should have exactly the same geometry but without all the complex maths in the background.

Rather than use cylinders, you could also use hexagonal prisms or some other approximation. Cylinders are much more complex shapes (lots more edges and vertices) so harder to deal with.

I’m trying to model the design as if it were cut out with an endmill because I want to use OpenSCAD to generate toolpaths.

So using a hexagon is out but the other suggestion should be perfectly fine.

Yes, but it adds an additional complexity, and won’t work with a ball-nosed endmill — I did do something similar when implementing a cove radius endmill, so will keep it in mind.

If you want to work with arbitrary endmill profiles:

  • Devise your profile
  • Rotate extrude 180 degrees
  • Linear extrude the length of the toolpath (center to center)
  • Rotate extrude again and rotate

This should still be a lot more efficient than the convex hull operation.

And I don’t think I’d agree that this is more complex than a hull operation. When you know what a hull operation is it might seem simpler but I think a lot of people wouldn’t be familiar with them, while union is pretty straightforward.

1 Like

Apparently there may be some internal improvements in a future version of OpenSCAD which may address this — we’ll have to see.

This topic was automatically closed after 30 days. New replies are no longer allowed.