KE
Karl Exler
Sun, May 21, 2023 5:11 PM
Dear all,
I have a SVG file, which I import into OpenScad. Then I make a border
and I swear that all meshes are connected. Nevertheless OpenSCAD says:
Rendering Polygon Mesh using CGAL... ERROR: The given mesh is not
closed! Unable to convert to CGAL_Nef_Polyhedron
I tried different things to avoid this, but no chance... Is there a way
to double check a SVG file..
and here is the code:
$fn=100;
path="wallpaper2.svg";
LB=127;
difference()
{
cube([LB,LB,1]);
translate([7,7,-0.1])
cube([LB-15,LB-15,1.2]);
};
translate([0.3,0.3,0])
//scale([0.056,0.056,1])
linear_extrude(1)
import(path);
many thanks
Karl
Dear all,
I have a SVG file, which I import into OpenScad. Then I make a border
and I swear that all meshes are connected. Nevertheless OpenSCAD says:
Rendering Polygon Mesh using CGAL... ERROR: The given mesh is not
closed! Unable to convert to CGAL_Nef_Polyhedron
I tried different things to avoid this, but no chance... Is there a way
to double check a SVG file..
and here is the code:
$fn=100;
path="wallpaper2.svg";
LB=127;
difference()
{
cube([LB,LB,1]);
translate([7,7,-0.1])
cube([LB-15,LB-15,1.2]);
};
translate([0.3,0.3,0])
//scale([0.056,0.056,1])
linear_extrude(1)
import(path);
many thanks
Karl
NH
nop head
Sun, May 21, 2023 5:18 PM
Try a miniscule offset before extruding it. Offset is done by the clipper
library that can fix these sort of problems.
On Sun, 21 May 2023, 18:11 Karl Exler, karl.exler@meinklang.cc wrote:
Dear all,
I have a SVG file, which I import into OpenScad. Then I make a border and
I swear that all meshes are connected. Nevertheless OpenSCAD says:
Rendering Polygon Mesh using CGAL... ERROR: The given mesh is not closed!
Unable to convert to CGAL_Nef_Polyhedron
I tried different things to avoid this, but no chance... Is there a way to
double check a SVG file..
and here is the code:
$fn=100; path="wallpaper2.svg"; LB=127;
difference() { cube([LB,LB,1]); translate([7,7,-0.1])
cube([LB-15,LB-15,1.2]); }; translate([0.3,0.3,0])
//scale([0.056,0.056,1]) linear_extrude(1) import(path);
many thanks
Karl
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Try a miniscule offset before extruding it. Offset is done by the clipper
library that can fix these sort of problems.
On Sun, 21 May 2023, 18:11 Karl Exler, <karl.exler@meinklang.cc> wrote:
> Dear all,
>
> I have a SVG file, which I import into OpenScad. Then I make a border and
> I swear that all meshes are connected. Nevertheless OpenSCAD says:
>
> Rendering Polygon Mesh using CGAL... ERROR: The given mesh is not closed!
> Unable to convert to CGAL_Nef_Polyhedron
>
> I tried different things to avoid this, but no chance... Is there a way to
> double check a SVG file..
>
> and here is the code:
> $fn=100; path="wallpaper2.svg"; LB=127;
> difference() { cube([LB,LB,1]); translate([7,7,-0.1])
> cube([LB-15,LB-15,1.2]); }; translate([0.3,0.3,0])
> //scale([0.056,0.056,1]) linear_extrude(1) import(path);
>
> many thanks
> Karl
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
JB
Jordan Brown
Mon, May 22, 2023 12:53 AM
I fed that SVG into my experimental OpenSCAD where I can look at the
geometry data, and found that the point [99.6916,13.7786] appears as
four consecutive points in one of the paths.
There are about forty points that are duplicated to one extent or
another. I suspect that a duplicated point is never healthy.
I don't know whether this duplication is in the SVG data or was somehow
caused by OpenSCAD's SVG import.
I fed that SVG into my experimental OpenSCAD where I can look at the
geometry data, and found that the point [99.6916,13.7786] appears as
four consecutive points in one of the paths.
There are about forty points that are duplicated to one extent or
another. I suspect that a duplicated point is never healthy.
I don't know whether this duplication is in the SVG data or was somehow
caused by OpenSCAD's SVG import.
RW
Rogier Wolff
Mon, May 22, 2023 8:44 AM
On Mon, May 22, 2023 at 12:53:27AM +0000, Jordan Brown wrote:
I fed that SVG into my experimental OpenSCAD where I can look at the
geometry data, and found that the point [99.6916,13.7786] appears as
four consecutive points in one of the paths.
There are about forty points that are duplicated to one extent or
another. I suspect that a duplicated point is never healthy.
I don't know whether this duplication is in the SVG data or was somehow
caused by OpenSCAD's SVG import.
I think this is another example why openscad needs more input/output
cleanup.
I think that if you structure it correctly it is easy to start out
simple and add sanitizer steps as required in the future.
Thus after an import call sanitizer (input_geometry).
Then in the sanitizer call all sanitizer functions in sequence.
In this case sanitizer_remove_duplicate_points_on_paths ();
which would be a simple function....
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a is going up. -- Chris Hadfield about flying up the space shuttle.
On Mon, May 22, 2023 at 12:53:27AM +0000, Jordan Brown wrote:
> I fed that SVG into my experimental OpenSCAD where I can look at the
> geometry data, and found that the point [99.6916,13.7786] appears as
> four consecutive points in one of the paths.
>
> There are about forty points that are duplicated to one extent or
> another. I suspect that a duplicated point is never healthy.
>
> I don't know whether this duplication is in the SVG data or was somehow
> caused by OpenSCAD's SVG import.
I think this is another example why openscad needs more input/output
cleanup.
I think that if you structure it correctly it is easy to start out
simple and add sanitizer steps as required in the future.
Thus after an import call sanitizer (input_geometry).
Then in the sanitizer call all sanitizer functions in sequence.
In this case sanitizer_remove_duplicate_points_on_paths ();
which would be a simple function....
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a is going up. -- Chris Hadfield about flying up the space shuttle.
KE
Karl Exler
Mon, May 22, 2023 12:42 PM
ahm... what can I do with this information.. of course I downloaded that
file from the Internet. Is there a was to find this mentioned point and
repair it?
thanks
Karl
Am 22.05.23 um 02:53 schrieb Jordan Brown:
I fed that SVG into my experimental OpenSCAD where I can look at the
geometry data, and found that the point [99.6916,13.7786] appears as
four consecutive points in one of the paths.
There are about forty points that are duplicated to one extent or
another. I suspect that a duplicated point is never healthy.
I don't know whether this duplication is in the SVG data or was
somehow caused by OpenSCAD's SVG import.
ahm... what can I do with this information.. of course I downloaded that
file from the Internet. Is there a was to find this mentioned point and
repair it?
thanks
Karl
Am 22.05.23 um 02:53 schrieb Jordan Brown:
> I fed that SVG into my experimental OpenSCAD where I can look at the
> geometry data, and found that the point [99.6916,13.7786] appears as
> four consecutive points in one of the paths.
>
> There are about forty points that are duplicated to one extent or
> another. I suspect that a duplicated point is never healthy.
>
> I don't know whether this duplication is in the SVG data or was
> somehow caused by OpenSCAD's SVG import.
>
>
J
jon
Mon, May 22, 2023 1:24 PM
Karl:
I imagine that if you had the kind of detailed analysis that Jordan
provided, you could manually edit the SVG file fairly easily. Of
course, this is tedious. I would also imagine that parsing the SVG file
and removing repeated points would be relatively easy to do as a
pre-processing phase prior to sending the SVG files to OpenSCAD.
Jon
On 5/22/2023 8:42 AM, Karl Exler wrote:
ahm... what can I do with this information.. of course I downloaded
that file from the Internet. Is there a was to find this mentioned
point and repair it?
thanks
Karl
Am 22.05.23 um 02:53 schrieb Jordan Brown:
I fed that SVG into my experimental OpenSCAD where I can look at the
geometry data, and found that the point [99.6916,13.7786] appears as
four consecutive points in one of the paths.
There are about forty points that are duplicated to one extent or
another. I suspect that a duplicated point is never healthy.
I don't know whether this duplication is in the SVG data or was
somehow caused by OpenSCAD's SVG import.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Karl:
I imagine that if you had the kind of detailed analysis that Jordan
provided, you could manually edit the SVG file fairly easily. Of
course, this is tedious. I would also imagine that parsing the SVG file
and removing repeated points would be relatively easy to do as a
pre-processing phase prior to sending the SVG files to OpenSCAD.
Jon
On 5/22/2023 8:42 AM, Karl Exler wrote:
> ahm... what can I do with this information.. of course I downloaded
> that file from the Internet. Is there a was to find this mentioned
> point and repair it?
> thanks
> Karl
>
> Am 22.05.23 um 02:53 schrieb Jordan Brown:
>> I fed that SVG into my experimental OpenSCAD where I can look at the
>> geometry data, and found that the point [99.6916,13.7786] appears as
>> four consecutive points in one of the paths.
>>
>> There are about forty points that are duplicated to one extent or
>> another. I suspect that a duplicated point is never healthy.
>>
>> I don't know whether this duplication is in the SVG data or was
>> somehow caused by OpenSCAD's SVG import.
>>
>>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
NH
nop head
Mon, May 22, 2023 1:25 PM
Did you try my suggestion of a tiny offset? It should fix duplicate
points and self intesections
On Mon, 22 May 2023 at 13:42, Karl Exler karl.exler@meinklang.cc wrote:
ahm... what can I do with this information.. of course I downloaded that
file from the Internet. Is there a was to find this mentioned point and
repair it?
thanks
Karl
Am 22.05.23 um 02:53 schrieb Jordan Brown:
I fed that SVG into my experimental OpenSCAD where I can look at the
geometry data, and found that the point [99.6916,13.7786] appears as
four consecutive points in one of the paths.
There are about forty points that are duplicated to one extent or
another. I suspect that a duplicated point is never healthy.
I don't know whether this duplication is in the SVG data or was
somehow caused by OpenSCAD's SVG import.
Did you try my suggestion of a tiny offset? It should fix duplicate
points and self intesections
On Mon, 22 May 2023 at 13:42, Karl Exler <karl.exler@meinklang.cc> wrote:
> ahm... what can I do with this information.. of course I downloaded that
> file from the Internet. Is there a was to find this mentioned point and
> repair it?
> thanks
> Karl
>
> Am 22.05.23 um 02:53 schrieb Jordan Brown:
> > I fed that SVG into my experimental OpenSCAD where I can look at the
> > geometry data, and found that the point [99.6916,13.7786] appears as
> > four consecutive points in one of the paths.
> >
> > There are about forty points that are duplicated to one extent or
> > another. I suspect that a duplicated point is never healthy.
> >
> > I don't know whether this duplication is in the SVG data or was
> > somehow caused by OpenSCAD's SVG import.
> >
> >
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
JW
Joe Weinpert
Mon, May 22, 2023 2:05 PM
The BOSL2 library contains a function called deduplicate() that removes
consecutive duplicates.
Joe Weinpert
skidrowacademy.com
On Mon, May 22, 2023 at 4:44 AM Rogier Wolff R.E.Wolff@bitwizard.nl wrote:
On Mon, May 22, 2023 at 12:53:27AM +0000, Jordan Brown wrote:
I fed that SVG into my experimental OpenSCAD where I can look at the
geometry data, and found that the point [99.6916,13.7786] appears as
four consecutive points in one of the paths.
There are about forty points that are duplicated to one extent or
another. I suspect that a duplicated point is never healthy.
I don't know whether this duplication is in the SVG data or was somehow
caused by OpenSCAD's SVG import.
I think this is another example why openscad needs more input/output
cleanup.
I think that if you structure it correctly it is easy to start out
simple and add sanitizer steps as required in the future.
Thus after an import call sanitizer (input_geometry).
Then in the sanitizer call all sanitizer functions in sequence.
In this case sanitizer_remove_duplicate_points_on_paths ();
which would be a simple function....
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110
**
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a is going up. -- Chris Hadfield about flying up the space shuttle.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
The BOSL2 library contains a function called *deduplicate()* that removes
consecutive duplicates.
Joe Weinpert
skidrowacademy.com
On Mon, May 22, 2023 at 4:44 AM Rogier Wolff <R.E.Wolff@bitwizard.nl> wrote:
> On Mon, May 22, 2023 at 12:53:27AM +0000, Jordan Brown wrote:
> > I fed that SVG into my experimental OpenSCAD where I can look at the
> > geometry data, and found that the point [99.6916,13.7786] appears as
> > four consecutive points in one of the paths.
> >
> > There are about forty points that are duplicated to one extent or
> > another. I suspect that a duplicated point is never healthy.
> >
> > I don't know whether this duplication is in the SVG data or was somehow
> > caused by OpenSCAD's SVG import.
>
> I think this is another example why openscad needs more input/output
> cleanup.
>
> I think that if you structure it correctly it is easy to start out
> simple and add sanitizer steps as required in the future.
>
> Thus after an import call sanitizer (input_geometry).
>
> Then in the sanitizer call all sanitizer functions in sequence.
>
> In this case sanitizer_remove_duplicate_points_on_paths ();
> which would be a simple function....
>
> Roger.
>
>
> --
> ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110
> **
> ** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
> f equals m times a. When your f is steady, and your m is going down
> your a is going up. -- Chris Hadfield about flying up the space shuttle.
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
J
jon
Mon, May 22, 2023 2:50 PM
deduplicate() is for a list, not for an SVG file. Is this a problem?
Jon
On 5/22/2023 10:05 AM, Joe Weinpert wrote:
The BOSL2 library contains a function called deduplicate() that
removes consecutive duplicates.
Joe Weinpert
skidrowacademy.com http://skidrowacademy.com
On Mon, May 22, 2023 at 4:44 AM Rogier Wolff R.E.Wolff@bitwizard.nl
wrote:
On Mon, May 22, 2023 at 12:53:27AM +0000, Jordan Brown wrote:
I fed that SVG into my experimental OpenSCAD where I can look at the
geometry data, and found that the point [99.6916,13.7786] appears as
four consecutive points in one of the paths.
There are about forty points that are duplicated to one extent or
another. I suspect that a duplicated point is never healthy.
I don't know whether this duplication is in the SVG data or was
caused by OpenSCAD's SVG import.
I think this is another example why openscad needs more input/output
cleanup.
I think that if you structure it correctly it is easy to start out
simple and add sanitizer steps as required in the future.
Thus after an import call sanitizer (input_geometry).
Then in the sanitizer call all sanitizer functions in sequence.
In this case sanitizer_remove_duplicate_points_on_paths ();
which would be a simple function....
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/
<https://www.BitWizard.nl/> ** +31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK:
27239233 **
f equals m times a. When your f is steady, and your m is going down
your a is going up. -- Chris Hadfield about flying up the space
shuttle.
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org
deduplicate() is for a list, not for an SVG file. Is this a problem?
Jon
On 5/22/2023 10:05 AM, Joe Weinpert wrote:
> The BOSL2 library contains a function called *deduplicate()* that
> removes consecutive duplicates.
>
> Joe Weinpert
> skidrowacademy.com <http://skidrowacademy.com>
>
>
>
>
> On Mon, May 22, 2023 at 4:44 AM Rogier Wolff <R.E.Wolff@bitwizard.nl>
> wrote:
>
> On Mon, May 22, 2023 at 12:53:27AM +0000, Jordan Brown wrote:
> > I fed that SVG into my experimental OpenSCAD where I can look at the
> > geometry data, and found that the point [99.6916,13.7786] appears as
> > four consecutive points in one of the paths.
> >
> > There are about forty points that are duplicated to one extent or
> > another. I suspect that a duplicated point is never healthy.
> >
> > I don't know whether this duplication is in the SVG data or was
> somehow
> > caused by OpenSCAD's SVG import.
>
> I think this is another example why openscad needs more input/output
> cleanup.
>
> I think that if you structure it correctly it is easy to start out
> simple and add sanitizer steps as required in the future.
>
> Thus after an import call sanitizer (input_geometry).
>
> Then in the sanitizer call all sanitizer functions in sequence.
>
> In this case sanitizer_remove_duplicate_points_on_paths ();
> which would be a simple function....
>
> Roger.
>
>
> --
> ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/
> <https://www.BitWizard.nl/> ** +31-15-2049110 **
> ** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK:
> 27239233 **
> f equals m times a. When your f is steady, and your m is going down
> your a is going up. -- Chris Hadfield about flying up the space
> shuttle.
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email todiscuss-leave@lists.openscad.org
JB
Jordan Brown
Mon, May 22, 2023 5:57 PM
On 5/22/2023 6:24 AM, jon wrote:
I imagine that if you had the kind of detailed analysis that Jordan
provided, you could manually edit the SVG file fairly easily. Of
course, this is tedious. I would also imagine that parsing the SVG
file and removing repeated points would be relatively easy to do as a
pre-processing phase prior to sending the SVG files to OpenSCAD.
I've now looked at the SVG file a little. It was simpler to read than I
remembered. I broke coordinate pairs into one per line, then |sort|uniq
-c|sort -n and found only one duplicated coordinate pair. That suggests
that the duplication that I observed in the OpenSCAD data is introduced
during OpenSCAD's import. (But without more analysis I couldn't say
whether it's mishandling of the Bézier curves or snapping to a grid or
what.) I didn't look at the structure of the curves; maybe there's
something degenerate about them.
One thing that makes analysis harder is that SVG's coordinate system and
OpenSCAD's are vertically flipped - OpenSCAD naturally treats +Y as
"up" while SVG treats it as "down". (OpenSCAD's model is the usual
mathematical model; SVG's is based on putting the origin at the top left
corner of a piece of paper.) This means that the import process has to
modify all of the coordinates, making it harder to find the matching
entries. I'm sure it's a simple transformation, but I don't know what
it is off the top of my head.
On 5/22/2023 6:24 AM, jon wrote:
> I imagine that if you had the kind of detailed analysis that Jordan
> provided, you could manually edit the SVG file fairly easily. Of
> course, this is tedious. I would also imagine that parsing the SVG
> file and removing repeated points would be relatively easy to do as a
> pre-processing phase prior to sending the SVG files to OpenSCAD.
I've now looked at the SVG file a little. It was simpler to read than I
remembered. I broke coordinate pairs into one per line, then |sort|uniq
-c|sort -n and found only one duplicated coordinate pair. That suggests
that the duplication that I observed in the OpenSCAD data is introduced
during OpenSCAD's import. (But without more analysis I couldn't say
whether it's mishandling of the Bézier curves or snapping to a grid or
what.) I didn't look at the structure of the curves; maybe there's
something degenerate about them.
One thing that makes analysis harder is that SVG's coordinate system and
OpenSCAD's are vertically flipped - OpenSCAD naturally treats +Y as
"up" while SVG treats it as "down". (OpenSCAD's model is the usual
mathematical model; SVG's is based on putting the origin at the top left
corner of a piece of paper.) This means that the import process has to
modify all of the coordinates, making it harder to find the matching
entries. I'm sure it's a simple transformation, but I don't know what
it is off the top of my head.
