avoiding geometry recalculation
Is there any way to perform a geometric calculation, store it, and then
retrieve it, to avoid recalculating the geometry every time I press F5
or F6?
I'm using BOSL2's Turtle3D, which is fine, but even a small series of
commands can take a long time to compute. So what I would want to store
is the resulting path, I think.
Were I to wish to store the sweep() over the path, I imagine I could
create an STL and then import() it as necessary.
I don't run into these kinds of performance problems very often, so I
don't have a best practice yet.
I've heard that render() can help, but it has never helped me.
Jon
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
OpenSCAD should have cached the geometry unless when the cache size is not
big enough. That said, for BOSL2, it is probably spending a lot of time
evaluating the OpenSCAD scripts prior to generating the csg tree, before
hitting the cache.
On Mon, Jan 26, 2026, 00:51 Jon Bondy via Discuss <
discuss@lists.openscad.org> wrote:
Is there any way to perform a geometric calculation, store it, and then
retrieve it, to avoid recalculating the geometry every time I press F5
or F6?
I'm using BOSL2's Turtle3D, which is fine, but even a small series of
commands can take a long time to compute. So what I would want to store
is the resulting path, I think.
Were I to wish to store the sweep() over the path, I imagine I could
create an STL and then import() it as necessary.
I don't run into these kinds of performance problems very often, so I
don't have a best practice yet.
I've heard that render() can help, but it has never helped me.
Jon
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On 1/25/2026 8:51 AM, Jon Bondy via Discuss wrote:
Is there any way to perform a geometric calculation, store it, and
then retrieve it, to avoid recalculating the geometry every time I
press F5 or F6?
Summary: no. (Other than, e.g., echoing the result and copy-and-pasting
it into a second file, and manually maintaining the relationship between
the two. Theoretically if you wanted to operate entirely in the CLI you
could automate such a process using a tool like "make".)
I've heard that render() can help, but it has never helped me.
When F6 rendering, OpenSCAD does caching of its geometry
calculations. That is, it can remember that the union of cube A and
cube B is shape C, so that the next time it encounters that particular
union it doesn't have to do the work.
That caching helped a lot with CGAL. With Manifold being so much faster
it's not as valuable, and the way it's done causes problems for Manifold
so there's active discussion of how the two fit together and I don't
know the current status.
That caching normally does not apply to an F5 preview, because it
normally doesn't do those calculations. However, if you use render()
it forces a full render of that subtree and caching does apply. That
processing (with or without caching) may help preview performance,
because while preview doesn't do that calculations that rendering does,
it does do other operations (every time you move the camera) that
rendering can reduce.
Somebody really should do a full write-up of the difference between
preview and render, and the ways that the two have different performance
characteristics. I'll take a stab at it if anybody is interested (and
then somebody who truly understands it can fix what I write :-).
But none of that helps you here, because your problem is the performance
of evaluating your OpenSCAD program, not the performance of rendering or
previewing the resulting geometry.
On 1/25/26 8:51 AM, Jon Bondy via Discuss wrote:
Is there any way to perform a geometric calculation, store it, and
then retrieve it, to avoid recalculating the geometry every time I
press F5 or F6?
Not within OpenSCAD.
See the discussion around
https://github.com/openscad/openscad/pull/4478#issuecomment-3650207368
It was specifically about operating on geometry literals, but also
applies to anything using VNF in BOSL2 as well.
Cory
Can you echo() the turtle's state vector, copy and paste, then reformat
into something that can be used in an include? For a one-off, it's
probably not worth the trouble, but if I'm understanding you correctly,
this could be a time-saver if it happens a lot (especially if you can
automate the reformatting).
On Sun, Jan 25, 2026 at 12:09 PM Cory Cross via Discuss <
discuss@lists.openscad.org> wrote:
On 1/25/26 8:51 AM, Jon Bondy via Discuss wrote:
Is there any way to perform a geometric calculation, store it, and
then retrieve it, to avoid recalculating the geometry every time I
press F5 or F6?
Not within OpenSCAD.
See the discussion around
https://github.com/openscad/openscad/pull/4478#issuecomment-3650207368
It was specifically about operating on geometry literals, but also
applies to anything using VNF in BOSL2 as well.
Cory
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Thank you.
I was using a path generated by turtle3D(). The time was taken up in
the path_sweep(). After I applied resample_path() and then
path_merge_collinear(), my execution time fell from 12 seconds to 3
seconds. Tolerable.
Jon
On 1/25/2026 1:08 PM, Cory Cross via Discuss wrote:
On 1/25/26 8:51 AM, Jon Bondy via Discuss wrote:
Is there any way to perform a geometric calculation, store it, and
then retrieve it, to avoid recalculating the geometry every time I
press F5 or F6?
Not within OpenSCAD.
It was specifically about operating on geometry literals, but also
applies to anything using VNF in BOSL2 as well.
Cory
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
I think it's important to identify where exactly the time is going. If you
have you code as:
path = turtle3d(...);
vnf = path_sweep(shape,path,...);
vnf_polyhedron(vnf);
then you can identify where the time is going more precisely by eliminating
the actual geometry instantiation at the end to see if it's making the
geometry of computation of the vnf that's taking the time. If you
really want to optimize your code and the time is going to
calculating the vnf then you could echo the vnf to the console and cut and
paste it into your code as a fixed expression. Pretty darn ugly...but it
would eliminate the computation step of path_sweep. (I sometimes have to
do this when debugging functions because there's no way to create geometry
in a function to visualize what's going wrong.) I would say that
path_sweep is not a particularly time consuming calculation, so I would
think that it would be the geometry creation that would dominate.
I made a box with a sine wave side wall where I computed a sine wave all
around the box and then had to do an offset to get the other side of the
wall. The sine wave changed with z, which meant I had a whole bunch of
different sine wave paths all going to offset, and the BOSL2 offset() is
slow. This ended up taking 90 seconds to compute, and nothing could be
cached because that computation had to happen with every F5 or F6. I
bought a faster computer...now only 20s to compute. (And yes, the pattern
is periodic in Z and I exploited that periodicity and did not just
recompute paths that were the same.) So for this situation, unless you
want to fix the geometry to a box of a specific size, or attempt some
complicated way to get the offset from a fragment of the box, there's
nothing to be done to make it faster.
[image: image.png]
On Sun, Jan 25, 2026 at 1:25 PM Jon Bondy via Discuss <
discuss@lists.openscad.org> wrote:
Thank you.
I was using a path generated by turtle3D(). The time was taken up in
the path_sweep(). After I applied resample_path() and then
path_merge_collinear(), my execution time fell from 12 seconds to 3
seconds. Tolerable.
Jon
On 1/25/2026 1:08 PM, Cory Cross via Discuss wrote:
On 1/25/26 8:51 AM, Jon Bondy via Discuss wrote:
Is there any way to perform a geometric calculation, store it, and
then retrieve it, to avoid recalculating the geometry every time I
press F5 or F6?
Not within OpenSCAD.
See the discussion around
It was specifically about operating on geometry literals, but also
applies to anything using VNF in BOSL2 as well.
Cory
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Side note:
In OpenSCAD, function evaluation and geometry evaluation are entirely
separate things. Geometry evaluation is already cached, to great effect.
But many BOSL2 features (like paths and sweeps) are implemented by
performing lengthy numerical calculations on arrays of numbers before
eventually drawing geometry with them.
One of the benefits of a functional programming language is that the
results of function evaluation can be "memoized", aka cached. Then if
the function is ever called again with the same arguments, it doesn't
need to be re-evaluated. In practice, this can be even more
transformative that you'd think. As an (impractical) example, the
Fibonacci function:
fib = function(n) n < 2 ? 1 : fib(n - 1) + fib(n - 2);
would normally take the age of the universe to calculate fib(100), but
with memoization it can return the answer in milliseconds. It's one of
the major features of the Haskell functional language (alongside lazy
evaluation).
Memoization is only possible if there is no outside influence on
function evaluation, such as global variables or I/O. I believe OpenSCAD
functions are perfectly amenable to memoization and it wouldn't be too
big a deal to add. If repeated calculations were cached across multiple
runs, Jon would get exactly what he wants in this case, and probably a
great many BOSL2 programs would go faster (potentially much faster), as
would the development cycle for them.
-Curt
On 1/25/26 08:51, Jon Bondy via Discuss wrote:
Is there any way to perform a geometric calculation, store it, and
then retrieve it, to avoid recalculating the geometry every time I
press F5 or F6?
I'm using BOSL2's Turtle3D, which is fine, but even a small series of
commands can take a long time to compute. So what I would want to
store is the resulting path, I think.
Were I to wish to store the sweep() over the path, I imagine I could
create an STL and then import() it as necessary.
I don't run into these kinds of performance problems very often, so I
don't have a best practice yet.
I've heard that render() can help, but it has never helped me.
On 1/25/2026 5:24 PM, Curt McDowell via Discuss wrote:
Memoization is only possible if there is no outside influence on
function evaluation, such as global variables or I/O. I
believe OpenSCAD functions are perfectly amenable to memoization and
it wouldn't be too big a deal to add. If repeated calculations were
cached across multiple runs, Jon would get exactly what he wants in
this case, and probably a great many BOSL2 programs would go faster
(potentially much faster), as would the development cycle for them.
Unfortunately, not perfectly amenable.
There are global-ish variables (both normal variables and $ variables),
plus the rands() function, that can throw a spanner in the works.
function f() = rands(0,1,1)[0];
function g() = $dollar;
module m(arg) {
function h() = arg;
...
}
and of course those could be buried arbitrarily deeply.
Shoot, we get the downsides of functional programming but not the upsides...
I suppose there could be a step that analyzes the AST and marks
functions that are OK to memoize and/or what to hash on. It would be a
pain to maintain though, and bug-phone.
Meh!
-Curt
On 1/25/26 19:51, Jordan Brown via Discuss wrote:
On 1/25/2026 5:24 PM, Curt McDowell via Discuss wrote:
Memoization is only possible if there is no outside influence on
function evaluation, such as global variables or I/O. I
believe OpenSCAD functions are perfectly amenable to memoization and
it wouldn't be too big a deal to add. If repeated calculations were
cached across multiple runs, Jon would get exactly what he wants in
this case, and probably a great many BOSL2 programs would go faster
(potentially much faster), as would the development cycle for them.
Unfortunately, not perfectly amenable.
There are global-ish variables (both normal variables and $
variables), plus the rands() function, that can throw a spanner in the
works.
function f() = rands(0,1,1)[0];
function g() = $dollar;
module m(arg) {
function h() = arg;
...
}
and of course those could be buried arbitrarily deeply.