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 (version 2020.12 RC3), 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/

_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.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.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

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/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

Hi Torsten,
thanks a lot, works with this "workaround"- actually i don't understand
why/how, but will find out ;-)



--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.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/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.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/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

Oh, and Ryps.svg and Ryps_fat.svg differ from line 27 on.





--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.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
> Discuss@.openscad

> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org





--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

On 27.12.2020 10:28, hugofant wrote: 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


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

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/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

Hi again,
thanks for all the ideas/solution/answers.
Seems that SVG isn't that easy to handle as expected, but i've a workaround
now and lots of information to work throught, for a better understanding of
that format...and also inkscape and openscad.
@lar3ry: the "base" for the "thin" file was created by a freelancer -
software unknown.
with inkscape i've changed all the "fillings" to black.
this was the "base" for the "fat" file - a thicker contour has been created
and then this contour has been converted to path....have also tried to find
the "tiny holes with self intersecting polygons", but doing this manually is
"torture" ;-)






--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

hugofant wrote
Thanks.
I do wonder why you made the "fat" file. When I worked with the "thin" file,
I removed the fill.
With SVG, there is path (stroke) and fill. If you change the stroke width in
Inkscape, it does not translate to a wider stroke in the STL exported. This
is because the svg only knows about a line, which is dimensionless. So in
your "thin" file, you only needed the stroke, and the fill was superfluous.
The STL only contained the stroke, and the "fill" generated was the result
of how OpenSCAD interpreted which enclosed paths to fill in.

Consider the following, using three different versions of Ryps.svg, the
first with strokes only, the second with fill only, and the third with both.

radius = 22.75;
height = 4.5;

filename_topside_image = "Ryps.svg";
filename_topside_image2 = "Ryps_fill_only.svg";
filename_topside_image3 = "Ryps_fill+stroke.svg";
topside_image_scale = 1.3;
//topside_image_scale = 5.5;
topside_image_zscale = 1.5;
topside_image_rotate = 0;

topside(filename_topside_image);
translate([20,0,0])
        topside(filename_topside_image2);
translate([40,0,0])
        topside(filename_topside_image3);

module topside(image) {
 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=image, center=true,dpi=300);

//    difference(){
//        cylinder(h=height/2,r=15,$fn=100);
//    }
         }
 }
}

all.png <http://forum.openscad.org/file/t2121/all.png>  


> have also tried to find the "tiny holes with self intersecting polygons",
> but doing this manually is "torture" ;-)

Indeed! After looking at an SVG file (for the first time), I think I
probably have the skill to parse the data section of one, to find unclosed
paths. That would be useful, of course, but it would be better if I could
find self-intersecting paths. I don't think my math skills are up to the
challenge, though, so the only way I can think of finding those would be to
step through each element in the path, displaying each element as it is
parsed, and manually looking at the result to see if a line crossed another
one. Heck, I probably don't have the skills to even display lines that are
part of elliptical arcs and Bezier curves.





--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org