problem with SVG import
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/
hugofant wrote
@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" ;-)
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);
// }
}
}
}
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/