discuss@lists.openscad.org

OpenSCAD general discussion Mailing-list

View all threads

Speed up SVG rendering

JC
Jesse Campbell
Thu, Sep 26, 2024 3:43 PM

I notice that some SVGs render quickly and some are slow on my web app:
https://mylabyrinthlab.com

For example,
Folder: https://mylabyrinthlab.com/data/zdjwnl/
File: https://mylabyrinthlab.com/data/zdjwnl/base.scad
File: https://mylabyrinthlab.com/data/zdjwnl/walls.scad

What are the steps in OpenSCAD to shorten rendering time?

What are ways to preprocess the SVG before loading into OpenSCAD?

I can add what works to the wikibook SVG page:
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/SVG_Import

I notice that some SVGs render quickly and some are slow on my web app: https://mylabyrinthlab.com For example, Folder: https://mylabyrinthlab.com/data/zdjwnl/ File: https://mylabyrinthlab.com/data/zdjwnl/base.scad File: https://mylabyrinthlab.com/data/zdjwnl/walls.scad What are the steps in OpenSCAD to shorten rendering time? What are ways to preprocess the SVG before loading into OpenSCAD? I can add what works to the wikibook SVG page: https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/SVG_Import
BC
Bob Carlson
Thu, Sep 26, 2024 5:35 PM

Enabling Manifold is the biggest thing. That requires a recent snapshot. I’ve been using snapshots for a long time with no problems. I also got an iMac with an M3 and that really helped too, but Manifold is free. I can set my $fn high and leave it there for the most part.

-Bob

On Sep 26, 2024, at 08:43, Jesse Campbell via Discuss discuss@lists.openscad.org wrote:

I notice that some SVGs render quickly and some are slow on my web app:
https://mylabyrinthlab.com

For example,
Folder: https://mylabyrinthlab.com/data/zdjwnl/
File: https://mylabyrinthlab.com/data/zdjwnl/base.scad
File: https://mylabyrinthlab.com/data/zdjwnl/walls.scad

What are the steps in OpenSCAD to shorten rendering time?

What are ways to preprocess the SVG before loading into OpenSCAD?

I can add what works to the wikibook SVG page:
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/SVG_Import


OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org

Enabling Manifold is the biggest thing. That requires a recent snapshot. I’ve been using snapshots for a long time with no problems. I also got an iMac with an M3 and that really helped too, but Manifold is free. I can set my $fn high and leave it there for the most part. -Bob > On Sep 26, 2024, at 08:43, Jesse Campbell via Discuss <discuss@lists.openscad.org> wrote: > > I notice that some SVGs render quickly and some are slow on my web app: > https://mylabyrinthlab.com > > For example, > Folder: https://mylabyrinthlab.com/data/zdjwnl/ > File: https://mylabyrinthlab.com/data/zdjwnl/base.scad > File: https://mylabyrinthlab.com/data/zdjwnl/walls.scad > > What are the steps in OpenSCAD to shorten rendering time? > > What are ways to preprocess the SVG before loading into OpenSCAD? > > I can add what works to the wikibook SVG page: > https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/SVG_Import > > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org
JB
Jordan Brown
Thu, Sep 26, 2024 6:05 PM

It's not the SVG, it's the offset().  Or rather, it's the offset() of
that SVG.

But the time that SVG is turned into an OpenSCAD object, it's got about
16,000 points.  Presumably offset has a hard time with that, especially
when the offset is causing basically everything to overlap.

I thought that $fa/$fs/$fn controlled the resolution used to convert SVG
curves into line segments, but it seems not.

One workaround is to use hull() instead of offset().  That runs almost
instantly.

It's not the SVG, it's the offset().  Or rather, it's the offset() of that SVG. But the time that SVG is turned into an OpenSCAD object, it's got about 16,000 points.  Presumably offset has a hard time with that, especially when the offset is causing basically everything to overlap. I thought that $fa/$fs/$fn controlled the resolution used to convert SVG curves into line segments, but it seems not. One workaround is to use hull() instead of offset().  That runs almost instantly.
TP
Torsten Paul
Thu, Sep 26, 2024 6:27 PM

On 26.09.24 20:05, Jordan Brown via Discuss wrote:

I thought that $fa/$fs/$fn controlled the resolution used to convert SVG
curves into line segments, but it seems not.

It does, BUT:

  • it can only subdivide, so if the SVG is already using very short
    segments, there's nothing the $fX parameters can do

  • segmentation tends to be on the high side as $fX is difficult to apply
    to arbitrary curve segments and right now it's not trying very hard

ciao,
Torsten.

On 26.09.24 20:05, Jordan Brown via Discuss wrote: > I thought that $fa/$fs/$fn controlled the resolution used to convert SVG > curves into line segments, but it seems not. It does, BUT: * it can only subdivide, so if the SVG is already using very short segments, there's nothing the $fX parameters can do * segmentation tends to be on the high side as $fX is difficult to apply to arbitrary curve segments and right now it's not trying very hard ciao, Torsten.
JC
Jesse Campbell
Fri, Sep 27, 2024 3:35 PM

I found a free, open-source web app / CLI program that does a good job
reducing complexity of SVGs.

Web app: https://jakearchibald.github.io/svgomg/
CLI program (Node.js): https://github.com/svg/svgo

Set variables "Number precision" and "Transform precision" in SVGO to
1/8.  OpenSCAD can run fast and not use so many primitive shapes.  Might
be good to pull it into OpenSCAD as library or plugin.

Sample SVG to try:
https://mylabyrinthlab.com/data/zdjwnl/large-chartrese-labyrinth-pointy-border.svg

The quality reduction isn't noticeable on these decorative items. 
Inkscape's "simplify" function is very noticeable and looks like a
really bad copy.

On 9/26/2024 2:27 PM, Torsten Paul via Discuss wrote:

On 26.09.24 20:05, Jordan Brown via Discuss wrote:

I thought that $fa/$fs/$fn controlled the resolution used to convert SVG
curves into line segments, but it seems not.

It does, BUT:

  • it can only subdivide, so if the SVG is already using very short
      segments, there's nothing the $fX parameters can do

  • segmentation tends to be on the high side as $fX is difficult to apply
      to arbitrary curve segments and right now it's not trying very hard

ciao,
  Torsten.


OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org

I found a free, open-source web app / CLI program that does a good job reducing complexity of SVGs. Web app: https://jakearchibald.github.io/svgomg/ CLI program (Node.js): https://github.com/svg/svgo Set variables "Number precision" and "Transform precision" in SVGO to 1/8.  OpenSCAD can run fast and not use so many primitive shapes.  Might be good to pull it into OpenSCAD as library or plugin. Sample SVG to try: https://mylabyrinthlab.com/data/zdjwnl/large-chartrese-labyrinth-pointy-border.svg The quality reduction isn't noticeable on these decorative items.  Inkscape's "simplify" function is very noticeable and looks like a really bad copy. On 9/26/2024 2:27 PM, Torsten Paul via Discuss wrote: > On 26.09.24 20:05, Jordan Brown via Discuss wrote: >> I thought that $fa/$fs/$fn controlled the resolution used to convert SVG >> curves into line segments, but it seems not. > > It does, BUT: > > * it can only subdivide, so if the SVG is already using very short >   segments, there's nothing the $fX parameters can do > > * segmentation tends to be on the high side as $fX is difficult to apply >   to arbitrary curve segments and right now it's not trying very hard > > ciao, >   Torsten. > > > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org
JB
Jordan Brown
Sun, Sep 29, 2024 4:49 PM

On 9/26/2024 11:27 AM, Torsten Paul via Discuss wrote:

On 26.09.24 20:05, Jordan Brown via Discuss wrote:

I thought that $fa/$fs/$fn controlled the resolution used to convert SVG
curves into line segments, but it seems not.

It does, BUT:

  • it can only subdivide, so if the SVG is already using very short
      segments, there's nothing the $fX parameters can do

  • segmentation tends to be on the high side as $fX is difficult to apply
      to arbitrary curve segments and right now it's not trying very hard

To close the loop for other readers, after our IRC conversation...

Only $fn applies, and it will only work to increase the resolution
(more segments, smaller segments) over the default resolution chosen. 
If the SVG has a curve, and OpenSCAD defaults to 100 segments for that
curve, only $fn values above 100 will have an effect.

On 9/26/2024 11:27 AM, Torsten Paul via Discuss wrote: > On 26.09.24 20:05, Jordan Brown via Discuss wrote: >> I thought that $fa/$fs/$fn controlled the resolution used to convert SVG >> curves into line segments, but it seems not. > > It does, BUT: > > * it can only subdivide, so if the SVG is already using very short >   segments, there's nothing the $fX parameters can do > > * segmentation tends to be on the high side as $fX is difficult to apply >   to arbitrary curve segments and right now it's not trying very hard To close the loop for other readers, after our IRC conversation... Only $fn applies, and it will only work to *increase* the resolution (more segments, smaller segments) over the default resolution chosen.  If the SVG has a curve, and OpenSCAD defaults to 100 segments for that curve, only $fn values above 100 will have an effect.
JC
Jesse Campbell
Sun, Sep 29, 2024 11:21 PM

I added SVGO to my web app process. The steps were:

  1. Download .zip of node.js and extract
  2. Run: npm install -g svgo
  3. Run: "...node folder"/svgo --input input.svg --output small.svg
    --precision 1

Precision argument can be 0 (smallest) to 8 (largest).
The time decreased greatly for all sample files.  The largest went from
about 40 seconds to 8 seconds.  Most samples now are less than 3 seconds.

The reason I use offset() instead of hull() is that offset() forms a
base that closely follows the shape of the input SVG.  Hull() sometimes
creates parts that are not in the input file.

On 9/29/2024 12:49 PM, Jordan Brown via Discuss wrote:

On 9/26/2024 11:27 AM, Torsten Paul via Discuss wrote:

On 26.09.24 20:05, Jordan Brown via Discuss wrote:

I thought that $fa/$fs/$fn controlled the resolution used to convert
SVG
curves into line segments, but it seems not.

It does, BUT:

  • it can only subdivide, so if the SVG is already using very short
      segments, there's nothing the $fX parameters can do

  • segmentation tends to be on the high side as $fX is difficult to apply
      to arbitrary curve segments and right now it's not trying very hard

To close the loop for other readers, after our IRC conversation...

Only $fn applies, and it will only work to increase the resolution
(more segments, smaller segments) over the default resolution chosen. 
If the SVG has a curve, and OpenSCAD defaults to 100 segments for that
curve, only $fn values above 100 will have an effect.


OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org

I added SVGO to my web app process. The steps were: 1. Download .zip of node.js and extract 2. Run: npm install -g svgo 3. Run: "...node folder"/svgo --input input.svg --output small.svg --precision 1 Precision argument can be 0 (smallest) to 8 (largest). The time decreased greatly for all sample files.  The largest went from about 40 seconds to 8 seconds.  Most samples now are less than 3 seconds. The reason I use offset() instead of hull() is that offset() forms a base that closely follows the shape of the input SVG.  Hull() sometimes creates parts that are not in the input file. On 9/29/2024 12:49 PM, Jordan Brown via Discuss wrote: > On 9/26/2024 11:27 AM, Torsten Paul via Discuss wrote: >> On 26.09.24 20:05, Jordan Brown via Discuss wrote: >>> I thought that $fa/$fs/$fn controlled the resolution used to convert >>> SVG >>> curves into line segments, but it seems not. >> >> It does, BUT: >> >> * it can only subdivide, so if the SVG is already using very short >>   segments, there's nothing the $fX parameters can do >> >> * segmentation tends to be on the high side as $fX is difficult to apply >>   to arbitrary curve segments and right now it's not trying very hard > > To close the loop for other readers, after our IRC conversation... > > Only $fn applies, and it will only work to *increase* the resolution > (more segments, smaller segments) over the default resolution chosen.  > If the SVG has a curve, and OpenSCAD defaults to 100 segments for that > curve, only $fn values above 100 will have an effect. > > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org
JB
Jordan Brown
Mon, Sep 30, 2024 12:18 AM

On 9/29/2024 4:21 PM, Jesse Campbell via Discuss wrote:

The reason I use offset() instead of hull() is that offset() forms a
base that closely follows the shape of the input SVG.  Hull() sometimes
creates parts that are not in the input file.

I'd be interested to see examples of what you mean.

Now, to be clear, this is for offset that is large relative to the
object - as is the case here.  If the offset is similar in size to the
concavities in the object, it's a different picture.

Enclosed below please find a test program to examine the differences.

For a simple test case (an X), here's the results:

Left is the original object.
Next is the difference between the original and the offset scheme - gray
is in both the original and the result, green is new in the result, and
red (of which there isn't any) is removed.
Third is the difference between the original and the hull scheme.
Fourth is the difference between the offset scheme and the hull scheme. 
(Gray is common, red is offset-only, green is hull-only.)

You'll notice that I set $fs and $fa.  Without those, the results for
the offset scheme are pretty ugly:

The results for the particular SVG have the two schemes almost
identical.  I won't include them here, because they're big if you want
to be able to see any differences, but you can experiment.

Those are with an offset of 100.  With an offset of 10, more around the
size of the concavities in the object, there's much more of a
difference.  With an offset of 5 (and the $fa/$fs settings):

$fs = 0.5;
$fa = 1;

offset_amount = 100;

module diff() {
color("gray") render() intersection() {
children(0);
children(1);
}
color("red") render() difference() {
children(0);
children(1);
intersection() {
children(0);
children(1);
}
}
color("green") render() difference() {
children(1);
children(0);
intersection() {
children(0);
children(1);
}
}
}

module test(sep) {
children();
translate([sep,0,0]) diff() {
children();
offset(-offset_amount) offset(offset_amount) children();
}
translate([sep2,0,0]) diff() {
children();
hull() children();
}
translate([sep
3, 0, 0]) diff() {
offset(-offset_amount) offset(offset_amount) children();
hull() children();

}

}

//test(150)
//    import("plain.svg",center=true,$fs=1000);

test(10) text("X");

On 9/29/2024 4:21 PM, Jesse Campbell via Discuss wrote: > The reason I use offset() instead of hull() is that offset() forms a > base that closely follows the shape of the input SVG.  Hull() sometimes > creates parts that are not in the input file. I'd be interested to see examples of what you mean. Now, to be clear, this is for offset that is large relative to the object - as is the case here.  If the offset is similar in size to the concavities in the object, it's a different picture. Enclosed below please find a test program to examine the differences. For a simple test case (an X), here's the results: Left is the original object. Next is the difference between the original and the offset scheme - gray is in both the original and the result, green is new in the result, and red (of which there isn't any) is removed. Third is the difference between the original and the hull scheme. Fourth is the difference between the offset scheme and the hull scheme.  (Gray is common, red is offset-only, green is hull-only.) You'll notice that I set $fs and $fa.  Without those, the results for the offset scheme are pretty ugly: The results for the particular SVG have the two schemes almost identical.  I won't include them here, because they're big if you want to be able to see any differences, but you can experiment. Those are with an offset of 100.  With an offset of 10, more around the size of the concavities in the object, there's much more of a difference.  With an offset of 5 (and the $fa/$fs settings): $fs = 0.5; $fa = 1; offset_amount = 100; module diff() { color("gray") render() intersection() { children(0); children(1); } color("red") render() difference() { children(0); children(1); intersection() { children(0); children(1); } } color("green") render() difference() { children(1); children(0); intersection() { children(0); children(1); } } } module test(sep) { children(); translate([sep,0,0]) diff() { children(); offset(-offset_amount) offset(offset_amount) children(); } translate([sep*2,0,0]) diff() { children(); hull() children(); } translate([sep*3, 0, 0]) diff() { offset(-offset_amount) offset(offset_amount) children(); hull() children(); } } //test(150) // import("plain.svg",center=true,$fs=1000); test(10) text("X");