problem with SVG import
Hi,
i want to create a coin with a SVG logo.
Import worked well, but Cura was not able to slice it correctly, cause of
walls to thing.
So i've created a contour with 0.4mm in inkscape, converted the contour to
path afterwards.
Import works well in openscad, and looks good with F5, but when rendering
with F6 i'm getting error
"ERROR: The given mesh is not closed! Unable to convert to
CGAL_Nef_Polyhedron., location unknown"
why is F5 working well and F6 not...and why is it working with the "thin"
file and causing an error with the "thick" one?
some ideas, help would be nice
thanks in advance and best regards
p.s.: and the header infos says that they have the same size....but during
import they are different....
the code:
/radius = 22.75;
height = 4.5;
filename_topside_image = "Ryps.svg";
topside_image_scale = 1.3;
//topside_image_scale = 5.5;
topside_image_zscale = 1.5;
topside_image_rotate = 180;
difference(){
union(){
translate([0,0,(height/2)-0.8 ])
linear_extrude(height=topside_image_zscale)
rotate([0,0,topside_image_rotate])
scale([topside_image_scale, topside_image_scale,
topside_image_zscale])
import(file=filename_topside_image, center=true,
dpi=300);
difference(){
cylinder(h=height/2,r=15,$fn=100);
}
}
}
/
and the two logos:
Ryps.svg http://forum.openscad.org/file/t3063/Ryps.svg
Ryps_fat.svg http://forum.openscad.org/file/t3063/Ryps_fat.svg
--
Sent from: http://forum.openscad.org/
On 27.12.20 10:28, hugofant wrote:
So i've created a contour with 0.4mm in inkscape, converted the
contour to path afterwards.
This seems to have created tiny holes with self intersecting
polygons.
One option is to process the 2D shape though offset() with a
tiny value, like offset(0.01) import("Ryps_fat.svg");
This might remove those polygons fixing the resulting 3D
object.
ciao,
Torsten.
You just need a newer version of OpenSCAD and/or a different slicer.
Using your .scad code, unmodified, I get no error rendering.
Exporting as stl, and slicing with Repetier-Host, it slices fine.
OpenSCAD 2020.12-RC3. Repetier-Host 2.1.6.
svgimport.jpg http://forum.openscad.org/file/t2121/svgimport.jpg
--
Sent from: http://forum.openscad.org/
Hi Torsten,
thanks a lot, works with ths "workaround"- actually i don't understand
why/how, but will find out ;-)
--
Sent from: http://forum.openscad.org/
Hi,
i'm already using the latest version of openscad and the unmodified .scad
code uses the "thin" file....rendering with the "thick" file is not working.
--
Sent from: http://forum.openscad.org/
hugofant wrote
Hi,
i'm already using the latest version of openscad and the unmodified .scad
code uses the "thin" file....rendering with the "thick" file is not
working.
oops.. my bad. Should read more carefully.
I've been playing around with it, and I think there is more going on here
that the width of the strokes.
I suspect that one or more of the paths in Ryps_fat.svg is not closed. I
played around with trying to find it, but it's a very big job manually, and
I don't see any way to find unclosed paths, without looking carefully at the
individual paths and playing around with all the nodes. There might well be
a way.
Torstens idea
This seems to have created tiny holes with self intersecting
polygons.
One option is to process the 2D shape though offset() with a
tiny value, like offset(0.01) import("Ryps_fat.svg");
probably works because offset creates a closed path regardless of whether or
not the path being offset is closed, and it might well remove
self-intersecting polygons.
Being svg files, they are probably not meant for 3D printing, but more for a
laser engraver/cutter or a CNC router. Either one of these uses would work
fine with unclosed paths.
Anyway, what I did was to load Ryps.svg into Inkscape, removed the fill
(which makes no difference in either the thin or fat versions), then made
the stroke 5.0mm. Looks like hell, but it's definitely 'fat'. When I import
that, preview works fine, and render works fine.
I would be interested in knowing how you made those files. Or did you
download them from somewhere?
I do not think it's an OpenSCAD problem.
--
Sent from: http://forum.openscad.org/
Oh, and Ryps.svg and Ryps_fat.svg differ from line 27 on.
--
Sent from: http://forum.openscad.org/
I haven't been following this thread closely, but it seems this might be
relevant:
https://github.com/openscad/openscad/issues/3430
Summary: OpenSCAD does not close filled paths which are not closed, instead
it leaves them open and gives them an arbitrary width and calls that filled.
I find this a problem because it does not conform to the specification (such
as it is) and some producers of SVG rely on the spec by NOT closing filled
paths assuming the consumer WILL close them prior to filling them.
My example is producing SVG using PostScript. Postscript closes open paths
prior to filling them and even when they are explicitly closed the utility I
use to produce the SVG from the PostScript omits the path closure segment.
It kind of makes sense since that segment is superfluous and omitting it
saves file space.
lar3ry wrote
hugofant wrote
Hi,
i'm already using the latest version of openscad and the unmodified .scad
code uses the "thin" file....rendering with the "thick" file is not
working.
oops.. my bad. Should read more carefully.
I've been playing around with it, and I think there is more going on here
that the width of the strokes.
I suspect that one or more of the paths in Ryps_fat.svg is not closed. I
played around with trying to find it, but it's a very big job manually,
and
I don't see any way to find unclosed paths, without looking carefully at
the
individual paths and playing around with all the nodes. There might well
be
a way.
Torstens idea
This seems to have created tiny holes with self intersecting
polygons.
One option is to process the 2D shape though offset() with a
tiny value, like offset(0.01) import("Ryps_fat.svg");
probably works because offset creates a closed path regardless of whether
or
not the path being offset is closed, and it might well remove
self-intersecting polygons.
Being svg files, they are probably not meant for 3D printing, but more for
a
laser engraver/cutter or a CNC router. Either one of these uses would work
fine with unclosed paths.
Anyway, what I did was to load Ryps.svg into Inkscape, removed the fill
(which makes no difference in either the thin or fat versions), then made
the stroke 5.0mm. Looks like hell, but it's definitely 'fat'. When I
import
that, preview works fine, and render works fine.
I would be interested in knowing how you made those files. Or did you
download them from somewhere?
I do not think it's an OpenSCAD problem.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@.openscad
--
Sent from: http://forum.openscad.org/
On 27.12.2020 10:28, hugofant wrote:
Hi,
i want to create a coin with a SVG logo.
Import worked well, but Cura was not able to slice it correctly, cause of
walls to thing.
So i've created a contour with 0.4mm in inkscape, converted the contour to
path afterwards.
Import works well in openscad, and looks good with F5, but when rendering
with F6 i'm getting error
"ERROR: The given mesh is not closed! Unable to convert to
CGAL_Nef_Polyhedron., location unknown"
Such files are often artistic drawings that look good, but may have
issues when interpreted as CAD models. As mentioned, at least one of the
files Ryps_fat.svg contains tiny details and perhaps self-intersecting
paths. Its scale is also very small compared to most models, and that
can cause issues if coordinate tolerances assume e.g. mm-scale.
An alternative approach that seems to work for this case is to first
convert the SVG to DXF: https://cloudconvert.com/svg-to-dxf
creating Ryps_fat.dxf
Then use AngelCADs dxfread utility to generate an .scad file while at
the same time auto-closing any open paths. It may also be an idea to
scale up the model in this step:
$ dxfread -scad -auto_close -scale=10 -sectol=0.001 Ryps_fat.dxf
The result is Ryps_fat.scad (attached). It seems to generate fewer
artifacts compared to importing the .svg directly.
Carsten Arnholm
I took Ryps_fat.svg apart in Notepad++, by separating out all the data
commands.
It looks like the Lines, Curves, Verticals, and Horizontals are all closed
with the Z, so it is more likely that there are self-intersecting lines.
--
Sent from: http://forum.openscad.org/