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
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
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.
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.
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
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.
I added SVGO to my web app process. The steps were:
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
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([sep3, 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");