M
MichaelAtOz
Sat, Dec 12, 2020 3:57 AM
What happens with lazy union if you don't union the top level items?
It does not do CSG so all top level objects are fully present.
i.e Cut in half to see internals.
With a union() the cube would be empty, and cube bits would not be inside the sweep'ed part.
BTW, the sweep has self-intersections.
-----Original Message-----
Sent: Sat, 12 Dec 2020 14:47
Subject: Re: [OpenSCAD] 2020.12-RC2 bogus model does not give CGAL error
It seems like a big gotcha for lazy union if forgetting to wrap your
top level in union() results in a bad STL output without a warning.
On Sat, Dec 12, 2020 at 02:39:46PM +1100, MichaelAtOz wrote:
(not posted to mailing-list)
Send me the STL if you want me to have a look at it.
-----Original Message-----
Sent: Sat, 12 Dec 2020 14:25
Subject: Re: [OpenSCAD] 2020.12-RC2 bogus model does not give CGAL error
I didn't even think of possible lazy union here. I know that lazy union is
enabled for my RC---I previously tested this. And yes, I did turn it on in
a snapshot, so that seems to explain why.
I wrapped with a union() and then I get a CGAL error as expected.
What happens with lazy union if you don't union the top level items? I took
my bad (?) file (without the top level union) and saved an STL and my slicer
seemed happy. (But I don't have the various mesh analysis tools everybody
uses to figure out just how bad the STL might be. Maybe PrusaSlicer is
really good at repairing/interpreting bad inputs.)
Windows 7, I get CGAL errors on both 2019.05 & RC2.
I get different console output.
On 2019.05, similar to Adrian's, but with the CGAL error after 'Rendering
Parsing design (AST generation)...
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
ERROR: CGAL error in CGALUtils::applyUnion3D: CGAL ERROR: assertion
G.mark(v1,0)==G.mark(v2,0)&& G.mark(v1,1)==G.mark(v2,1) File:
/mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_S2/SM_overlayer.h
UI-WARNING: No top level geometry to render location unknown
i.e no cache stats or time.
Did you use a snapshot to test Lazy-Union?
Wrap the path_sweep & cube in a union.
-----Original Message-----
discuss-bounces@.openscad
Sent: Sat, 12 Dec 2020 12:00
Subject: [OpenSCAD] 2020.12-RC2 bogus model does not give CGAL error
I wrote the code below to help a user on another thread, but I noticed a
weird thing. With the parameters below, the sweep gives a bad polyhedron
with self-intersections. And yet, with the RC I do not get a CGAL error,
least under Linux. With 2019.05 I do get a CGAL error, but under the
Parsing design (AST generation)...
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
Geometry cache size in bytes: 1662680
CGAL Polyhedrons in cache: 0
CGAL cache size in bytes: 0
Total rendering time: 0:00:00.582
Top level object is a list of objects:
path = [for(i=[0:2:359]) (r+ofssin(numberi))*[cos(i),sin(i)]];
path_sweep(circle(r=radius), path, closed=true);
I've also noticed that the RC doesn't always print blank lines before
starting a new computation, which can make it hard to read the output.
This email has been checked for viruses by AVG.
This email has been checked for viruses by AVG.
> What happens with lazy union if you don't union the top level items?
It does not do CSG so all top level objects are fully present.
i.e Cut in half to see internals.
With a union() the cube would be empty, and cube bits would not be inside the sweep'ed part.
BTW, the sweep has self-intersections.
> -----Original Message-----
> From: Adrian Mariano [mailto:radian@cox.net]
> Sent: Sat, 12 Dec 2020 14:47
> To: MichaelAtOz
> Subject: Re: [OpenSCAD] 2020.12-RC2 bogus model does not give CGAL error
>
> STL attached.
>
> It seems like a big gotcha for lazy union if forgetting to wrap your
> top level in union() results in a bad STL output without a warning.
>
> On Sat, Dec 12, 2020 at 02:39:46PM +1100, MichaelAtOz wrote:
> > (not posted to mailing-list)
> >
> > Adrian,
> >
> > Send me the STL if you want me to have a look at it.
> >
> > Michael
> >
> > > -----Original Message-----
> > > From: Discuss [mailto:discuss-bounces@lists.openscad.org] On Behalf Of adrianv
> > > Sent: Sat, 12 Dec 2020 14:25
> > > To: discuss@lists.openscad.org
> > > Subject: Re: [OpenSCAD] 2020.12-RC2 bogus model does not give CGAL error
> > >
> > > I didn't even think of possible lazy union here. I know that lazy union is
> > > enabled for my RC---I previously tested this. And yes, I did turn it on in
> > > a snapshot, so that seems to explain why.
> > >
> > > I wrapped with a union() and then I get a CGAL error as expected.
> > >
> > > What happens with lazy union if you don't union the top level items? I took
> > > my bad (?) file (without the top level union) and saved an STL and my slicer
> > > seemed happy. (But I don't have the various mesh analysis tools everybody
> > > uses to figure out just how bad the STL might be. Maybe PrusaSlicer is
> > > really good at repairing/interpreting bad inputs.)
> > >
> > >
> > > MichaelAtOz wrote
> > > > Windows 7, I get CGAL errors on both 2019.05 & RC2.
> > > >
> > > > I get different console output.
> > > > On 2019.05, similar to Adrian's, but with the CGAL error after 'Rendering
> > > > Polygon Mesh using
> > > > CGAL...'.
> > > >
> > > > RC2 is truncated:
> > > >
> > > > Parsing design (AST generation)...
> > > > Compiling design (CSG Tree generation)...
> > > > Rendering Polygon Mesh using CGAL...
> > > > ERROR: CGAL error in CGALUtils::applyUnion3D: CGAL ERROR: assertion
> > > > violation! Expr:
> > > > G.mark(v1,0)==G.mark(v2,0)&& G.mark(v1,1)==G.mark(v2,1) File:
> > > > /mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_S2/SM_overlayer.h
> > > > Line: 303, location
> > > > unknown
> > > > UI-WARNING: No top level geometry to render location unknown
> > > >
> > > > i.e no cache stats or time.
> > > >
> > > > Adrian, see https://github.com/openscad/openscad/issues/3517
> > > > Did you use a snapshot to test Lazy-Union?
> > > >
> > > > Wrap the path_sweep & cube in a union.
> > > >
> > > >> -----Original Message-----
> > > >> From: Discuss [mailto:
> > >
> > > > discuss-bounces@.openscad
> > >
> > > > ] On Behalf Of adrianv
> > > >> Sent: Sat, 12 Dec 2020 12:00
> > > >> To:
> > >
> > > > discuss@.openscad
> > >
> > > >> Subject: [OpenSCAD] 2020.12-RC2 bogus model does not give CGAL error
> > > >>
> > > >> I wrote the code below to help a user on another thread, but I noticed a
> > > >> weird thing. With the parameters below, the sweep gives a bad polyhedron
> > > >> with self-intersections. And yet, with the RC I do not get a CGAL error,
> > > >> at
> > > >> least under Linux. With 2019.05 I do get a CGAL error, but under the
> > > >> RC:
> > > >>
> > > >> Parsing design (AST generation)...
> > > >> Compiling design (CSG Tree generation)...
> > > >> Rendering Polygon Mesh using CGAL...
> > > >> Geometries in cache: 7
> > > >> Geometry cache size in bytes: 1662680
> > > >> CGAL Polyhedrons in cache: 0
> > > >> CGAL cache size in bytes: 0
> > > >> Total rendering time: 0:00:00.582
> > > >> Top level object is a list of objects:
> > > >> Objects: 2
> > > >> Rendering finished.
> > > >>
> > > >>
> > > >> include<BOSL2/std.scad>
> > > >> include<BOSL2/skin.scad>
> > > >>
> > > >> $fn=16;
> > > >> ofs = 1;
> > > >> r=4;
> > > >> number=5;
> > > >> radius=1.4;
> > > >>
> > > >> path = [for(i=[0:2:359]) (r+ofs*sin(number*i))*[cos(i),sin(i)]];
> > > >> path_sweep(circle(r=radius), path, closed=true);
> > > >> cube(8);
> > > >>
> > > >>
> > > >> I've also noticed that the RC doesn't always print blank lines before
> > > >> starting a new computation, which can make it hard to read the output.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Sent from: http://forum.openscad.org/
> > > >>
> > > >> _______________________________________________
> > > >> OpenSCAD mailing list
> > > >>
> > >
> > > > Discuss@.openscad
> > >
> > > >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
> > > >
> > > >
> > > > --
> > > > This email has been checked for viruses by AVG.
> > > > https://www.avg.com
> > > >
> > > >
> > > > _______________________________________________
> > > > OpenSCAD mailing list
> > >
> > > > Discuss@.openscad
> > >
> > > > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
> > >
> > >
> > >
> > >
> > >
> > > --
> > > Sent from: http://forum.openscad.org/
> > >
> > > _______________________________________________
> > > OpenSCAD mailing list
> > > Discuss@lists.openscad.org
> > > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
> >
> >
> > --
> > This email has been checked for viruses by AVG.
> > https://www.avg.com
--
This email has been checked for viruses by AVG.
https://www.avg.com
HL
Hans L
Sat, Dec 12, 2020 4:21 AM
Yep with Lazy union, multiple top level objects can be exported. Whether
they are disjoint or not, it's up to the user (or slicer, as it may be) to
deal with.
Honestly, I'm not sure how well various slicers handle overlapping objects,
ie if they properly union the results themselves, or could possibly
generate overlapping toolpaths which "double extrude", or force each object
to be arranged separately on the build plate.
By the way, the lines from your console output are a dead giveaway that
lazy union is enabled:
Top level object is a list of objects:
Objects: 2
That "list of objects" is only possible with lazy union.
On Fri, Dec 11, 2020 at 9:58 PM MichaelAtOz oz.at.michael@gmail.com wrote:
What happens with lazy union if you don't union the top level items?
It does not do CSG so all top level objects are fully present.
i.e Cut in half to see internals.
With a union() the cube would be empty, and cube bits would not be inside
the sweep'ed part.
BTW, the sweep has self-intersections.
-----Original Message-----
Sent: Sat, 12 Dec 2020 14:47
Subject: Re: [OpenSCAD] 2020.12-RC2 bogus model does not give CGAL error
It seems like a big gotcha for lazy union if forgetting to wrap your
top level in union() results in a bad STL output without a warning.
On Sat, Dec 12, 2020 at 02:39:46PM +1100, MichaelAtOz wrote:
(not posted to mailing-list)
Send me the STL if you want me to have a look at it.
-----Original Message-----
Sent: Sat, 12 Dec 2020 14:25
Subject: Re: [OpenSCAD] 2020.12-RC2 bogus model does not give CGAL
I didn't even think of possible lazy union here. I know that lazy
enabled for my RC---I previously tested this. And yes, I did turn
a snapshot, so that seems to explain why.
I wrapped with a union() and then I get a CGAL error as expected.
What happens with lazy union if you don't union the top level
my bad (?) file (without the top level union) and saved an STL and
seemed happy. (But I don't have the various mesh analysis tools
uses to figure out just how bad the STL might be. Maybe PrusaSlicer
really good at repairing/interpreting bad inputs.)
Windows 7, I get CGAL errors on both 2019.05 & RC2.
I get different console output.
On 2019.05, similar to Adrian's, but with the CGAL error after
Parsing design (AST generation)...
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
ERROR: CGAL error in CGALUtils::applyUnion3D: CGAL ERROR: assertion
G.mark(v1,0)==G.mark(v2,0)&& G.mark(v1,1)==G.mark(v2,1) File:
/mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_S2/SM_overlayer.h
UI-WARNING: No top level geometry to render location unknown
i.e no cache stats or time.
Did you use a snapshot to test Lazy-Union?
Wrap the path_sweep & cube in a union.
-----Original Message-----
discuss-bounces@.openscad
Sent: Sat, 12 Dec 2020 12:00
Subject: [OpenSCAD] 2020.12-RC2 bogus model does not give CGAL
I wrote the code below to help a user on another thread, but I
weird thing. With the parameters below, the sweep gives a bad
with self-intersections. And yet, with the RC I do not get a
least under Linux. With 2019.05 I do get a CGAL error, but
Parsing design (AST generation)...
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
Geometry cache size in bytes: 1662680
CGAL Polyhedrons in cache: 0
CGAL cache size in bytes: 0
Total rendering time: 0:00:00.582
Top level object is a list of objects:
path = [for(i=[0:2:359]) (r+ofssin(numberi))*[cos(i),sin(i)]];
path_sweep(circle(r=radius), path, closed=true);
I've also noticed that the RC doesn't always print blank lines
starting a new computation, which can make it hard to read the
This email has been checked for viruses by AVG.
This email has been checked for viruses by AVG.
Yep with Lazy union, multiple top level objects can be exported. Whether
they are disjoint or not, it's up to the user (or slicer, as it may be) to
deal with.
Honestly, I'm not sure how well various slicers handle overlapping objects,
ie if they properly union the results themselves, or could possibly
generate overlapping toolpaths which "double extrude", or force each object
to be arranged separately on the build plate.
By the way, the lines from your console output are a dead giveaway that
lazy union is enabled:
Top level object is a list of objects:
Objects: 2
That "list of objects" is only possible with lazy union.
On Fri, Dec 11, 2020 at 9:58 PM MichaelAtOz <oz.at.michael@gmail.com> wrote:
> > What happens with lazy union if you don't union the top level items?
>
>
>
> It does not do CSG so all top level objects are fully present.
>
>
>
> i.e Cut in half to see internals.
>
>
>
>
>
> With a union() the cube would be empty, and cube bits would not be inside
> the sweep'ed part.
>
>
>
> BTW, the sweep has self-intersections.
>
>
>
>
>
>
>
>
>
>
>
>
>
> > -----Original Message-----
>
> > From: Adrian Mariano [mailto:radian@cox.net]
>
> > Sent: Sat, 12 Dec 2020 14:47
>
> > To: MichaelAtOz
>
> > Subject: Re: [OpenSCAD] 2020.12-RC2 bogus model does not give CGAL error
>
> >
>
> > STL attached.
>
> >
>
> > It seems like a big gotcha for lazy union if forgetting to wrap your
>
> > top level in union() results in a bad STL output without a warning.
>
> >
>
> > On Sat, Dec 12, 2020 at 02:39:46PM +1100, MichaelAtOz wrote:
>
> > > (not posted to mailing-list)
>
> > >
>
> > > Adrian,
>
> > >
>
> > > Send me the STL if you want me to have a look at it.
>
> > >
>
> > > Michael
>
> > >
>
> > > > -----Original Message-----
>
> > > > From: Discuss [mailto:discuss-bounces@lists.openscad.org] On Behalf
> Of adrianv
>
> > > > Sent: Sat, 12 Dec 2020 14:25
>
> > > > To: discuss@lists.openscad.org
>
> > > > Subject: Re: [OpenSCAD] 2020.12-RC2 bogus model does not give CGAL
> error
>
> > > >
>
> > > > I didn't even think of possible lazy union here. I know that lazy
> union is
>
> > > > enabled for my RC---I previously tested this. And yes, I did turn
> it on in
>
> > > > a snapshot, so that seems to explain why.
>
> > > >
>
> > > > I wrapped with a union() and then I get a CGAL error as expected.
>
> > > >
>
> > > > What happens with lazy union if you don't union the top level
> items? I took
>
> > > > my bad (?) file (without the top level union) and saved an STL and
> my slicer
>
> > > > seemed happy. (But I don't have the various mesh analysis tools
> everybody
>
> > > > uses to figure out just how bad the STL might be. Maybe PrusaSlicer
> is
>
> > > > really good at repairing/interpreting bad inputs.)
>
> > > >
>
> > > >
>
> > > > MichaelAtOz wrote
>
> > > > > Windows 7, I get CGAL errors on both 2019.05 & RC2.
>
> > > > >
>
> > > > > I get different console output.
>
> > > > > On 2019.05, similar to Adrian's, but with the CGAL error after
> 'Rendering
>
> > > > > Polygon Mesh using
>
> > > > > CGAL...'.
>
> > > > >
>
> > > > > RC2 is truncated:
>
> > > > >
>
> > > > > Parsing design (AST generation)...
>
> > > > > Compiling design (CSG Tree generation)...
>
> > > > > Rendering Polygon Mesh using CGAL...
>
> > > > > ERROR: CGAL error in CGALUtils::applyUnion3D: CGAL ERROR: assertion
>
> > > > > violation! Expr:
>
> > > > > G.mark(v1,0)==G.mark(v2,0)&& G.mark(v1,1)==G.mark(v2,1) File:
>
> > > > >
> /mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_S2/SM_overlayer.h
>
> > > > > Line: 303, location
>
> > > > > unknown
>
> > > > > UI-WARNING: No top level geometry to render location unknown
>
> > > > >
>
> > > > > i.e no cache stats or time.
>
> > > > >
>
> > > > > Adrian, see https://github.com/openscad/openscad/issues/3517
>
> > > > > Did you use a snapshot to test Lazy-Union?
>
> > > > >
>
> > > > > Wrap the path_sweep & cube in a union.
>
> > > > >
>
> > > > >> -----Original Message-----
>
> > > > >> From: Discuss [mailto:
>
> > > >
>
> > > > > discuss-bounces@.openscad
>
> > > >
>
> > > > > ] On Behalf Of adrianv
>
> > > > >> Sent: Sat, 12 Dec 2020 12:00
>
> > > > >> To:
>
> > > >
>
> > > > > discuss@.openscad
>
> > > >
>
> > > > >> Subject: [OpenSCAD] 2020.12-RC2 bogus model does not give CGAL
> error
>
> > > > >>
>
> > > > >> I wrote the code below to help a user on another thread, but I
> noticed a
>
> > > > >> weird thing. With the parameters below, the sweep gives a bad
> polyhedron
>
> > > > >> with self-intersections. And yet, with the RC I do not get a
> CGAL error,
>
> > > > >> at
>
> > > > >> least under Linux. With 2019.05 I do get a CGAL error, but
> under the
>
> > > > >> RC:
>
> > > > >>
>
> > > > >> Parsing design (AST generation)...
>
> > > > >> Compiling design (CSG Tree generation)...
>
> > > > >> Rendering Polygon Mesh using CGAL...
>
> > > > >> Geometries in cache: 7
>
> > > > >> Geometry cache size in bytes: 1662680
>
> > > > >> CGAL Polyhedrons in cache: 0
>
> > > > >> CGAL cache size in bytes: 0
>
> > > > >> Total rendering time: 0:00:00.582
>
> > > > >> Top level object is a list of objects:
>
> > > > >> Objects: 2
>
> > > > >> Rendering finished.
>
> > > > >>
>
> > > > >>
>
> > > > >> include<BOSL2/std.scad>
>
> > > > >> include<BOSL2/skin.scad>
>
> > > > >>
>
> > > > >> $fn=16;
>
> > > > >> ofs = 1;
>
> > > > >> r=4;
>
> > > > >> number=5;
>
> > > > >> radius=1.4;
>
> > > > >>
>
> > > > >> path = [for(i=[0:2:359]) (r+ofs*sin(number*i))*[cos(i),sin(i)]];
>
> > > > >> path_sweep(circle(r=radius), path, closed=true);
>
> > > > >> cube(8);
>
> > > > >>
>
> > > > >>
>
> > > > >> I've also noticed that the RC doesn't always print blank lines
> before
>
> > > > >> starting a new computation, which can make it hard to read the
> output.
>
> > > > >>
>
> > > > >>
>
> > > > >>
>
> > > > >>
>
> > > > >> --
>
> > > > >> Sent from: http://forum.openscad.org/
>
> > > > >>
>
> > > > >> _______________________________________________
>
> > > > >> OpenSCAD mailing list
>
> > > > >>
>
> > > >
>
> > > > > Discuss@.openscad
>
> > > >
>
> > > > >>
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
> > > > >
>
> > > > >
>
> > > > > --
>
> > > > > This email has been checked for viruses by AVG.
>
> > > > > https://www.avg.com
>
> > > > >
>
> > > > >
>
> > > > > _______________________________________________
>
> > > > > OpenSCAD mailing list
>
> > > >
>
> > > > > Discuss@.openscad
>
> > > >
>
> > > > >
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
> > > >
>
> > > >
>
> > > >
>
> > > >
>
> > > >
>
> > > > --
>
> > > > Sent from: http://forum.openscad.org/
>
> > > >
>
> > > > _______________________________________________
>
> > > > OpenSCAD mailing list
>
> > > > Discuss@lists.openscad.org
>
> > > >
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
> > >
>
> > >
>
> > > --
>
> > > This email has been checked for viruses by AVG.
>
> > > https://www.avg.com
>
>
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free.
> www.avg.com
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
> <#m_2570480591202271868_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
NH
nop head
Sat, Dec 12, 2020 9:12 AM
Honestly, I'm not sure how well various slicers handle overlapping objects
Skeinforge XORs them so you end up with unexpected voids where they overlap.
I don't think OpenSCAD should export STLs with overlapping volumes.
On Sat, 12 Dec 2020 at 04:22, Hans L thehans@gmail.com wrote:
Yep with Lazy union, multiple top level objects can be exported. Whether
they are disjoint or not, it's up to the user (or slicer, as it may be) to
deal with.
Honestly, I'm not sure how well various slicers handle overlapping
objects, ie if they properly union the results themselves, or could
possibly generate overlapping toolpaths which "double extrude", or force
each object to be arranged separately on the build plate.
By the way, the lines from your console output are a dead giveaway that
lazy union is enabled:
Top level object is a list of objects:
Objects: 2
That "list of objects" is only possible with lazy union.
On Fri, Dec 11, 2020 at 9:58 PM MichaelAtOz oz.at.michael@gmail.com
wrote:
What happens with lazy union if you don't union the top level items?
It does not do CSG so all top level objects are fully present.
i.e Cut in half to see internals.
With a union() the cube would be empty, and cube bits would not be inside
the sweep'ed part.
BTW, the sweep has self-intersections.
-----Original Message-----
Sent: Sat, 12 Dec 2020 14:47
Subject: Re: [OpenSCAD] 2020.12-RC2 bogus model does not give CGAL
It seems like a big gotcha for lazy union if forgetting to wrap your
top level in union() results in a bad STL output without a warning.
On Sat, Dec 12, 2020 at 02:39:46PM +1100, MichaelAtOz wrote:
(not posted to mailing-list)
Send me the STL if you want me to have a look at it.
-----Original Message-----
Sent: Sat, 12 Dec 2020 14:25
Subject: Re: [OpenSCAD] 2020.12-RC2 bogus model does not give CGAL
I didn't even think of possible lazy union here. I know that lazy
enabled for my RC---I previously tested this. And yes, I did turn
a snapshot, so that seems to explain why.
I wrapped with a union() and then I get a CGAL error as expected.
What happens with lazy union if you don't union the top level
my bad (?) file (without the top level union) and saved an STL and
seemed happy. (But I don't have the various mesh analysis tools
uses to figure out just how bad the STL might be. Maybe
really good at repairing/interpreting bad inputs.)
Windows 7, I get CGAL errors on both 2019.05 & RC2.
I get different console output.
On 2019.05, similar to Adrian's, but with the CGAL error after
Parsing design (AST generation)...
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
ERROR: CGAL error in CGALUtils::applyUnion3D: CGAL ERROR:
G.mark(v1,0)==G.mark(v2,0)&& G.mark(v1,1)==G.mark(v2,1) File:
/mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_S2/SM_overlayer.h
UI-WARNING: No top level geometry to render location unknown
i.e no cache stats or time.
Did you use a snapshot to test Lazy-Union?
Wrap the path_sweep & cube in a union.
-----Original Message-----
discuss-bounces@.openscad
Sent: Sat, 12 Dec 2020 12:00
Subject: [OpenSCAD] 2020.12-RC2 bogus model does not give CGAL
I wrote the code below to help a user on another thread, but I
weird thing. With the parameters below, the sweep gives a bad
with self-intersections. And yet, with the RC I do not get a
least under Linux. With 2019.05 I do get a CGAL error, but
Parsing design (AST generation)...
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
Geometry cache size in bytes: 1662680
CGAL Polyhedrons in cache: 0
CGAL cache size in bytes: 0
Total rendering time: 0:00:00.582
Top level object is a list of objects:
path = [for(i=[0:2:359]) (r+ofssin(numberi))*[cos(i),sin(i)]];
path_sweep(circle(r=radius), path, closed=true);
I've also noticed that the RC doesn't always print blank lines
starting a new computation, which can make it hard to read the
This email has been checked for viruses by AVG.
This email has been checked for viruses by AVG.
> Honestly, I'm not sure how well various slicers handle overlapping objects
Skeinforge XORs them so you end up with unexpected voids where they overlap.
I don't think OpenSCAD should export STLs with overlapping volumes.
On Sat, 12 Dec 2020 at 04:22, Hans L <thehans@gmail.com> wrote:
> Yep with Lazy union, multiple top level objects can be exported. Whether
> they are disjoint or not, it's up to the user (or slicer, as it may be) to
> deal with.
>
> Honestly, I'm not sure how well various slicers handle overlapping
> objects, ie if they properly union the results themselves, or could
> possibly generate overlapping toolpaths which "double extrude", or force
> each object to be arranged separately on the build plate.
>
> By the way, the lines from your console output are a dead giveaway that
> lazy union is enabled:
> Top level object is a list of objects:
> Objects: 2
>
> That "list of objects" is only possible with lazy union.
>
>
> On Fri, Dec 11, 2020 at 9:58 PM MichaelAtOz <oz.at.michael@gmail.com>
> wrote:
>
>> > What happens with lazy union if you don't union the top level items?
>>
>>
>>
>> It does not do CSG so all top level objects are fully present.
>>
>>
>>
>> i.e Cut in half to see internals.
>>
>>
>>
>>
>>
>> With a union() the cube would be empty, and cube bits would not be inside
>> the sweep'ed part.
>>
>>
>>
>> BTW, the sweep has self-intersections.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> > -----Original Message-----
>>
>> > From: Adrian Mariano [mailto:radian@cox.net]
>>
>> > Sent: Sat, 12 Dec 2020 14:47
>>
>> > To: MichaelAtOz
>>
>> > Subject: Re: [OpenSCAD] 2020.12-RC2 bogus model does not give CGAL
>> error
>>
>> >
>>
>> > STL attached.
>>
>> >
>>
>> > It seems like a big gotcha for lazy union if forgetting to wrap your
>>
>> > top level in union() results in a bad STL output without a warning.
>>
>> >
>>
>> > On Sat, Dec 12, 2020 at 02:39:46PM +1100, MichaelAtOz wrote:
>>
>> > > (not posted to mailing-list)
>>
>> > >
>>
>> > > Adrian,
>>
>> > >
>>
>> > > Send me the STL if you want me to have a look at it.
>>
>> > >
>>
>> > > Michael
>>
>> > >
>>
>> > > > -----Original Message-----
>>
>> > > > From: Discuss [mailto:discuss-bounces@lists.openscad.org] On
>> Behalf Of adrianv
>>
>> > > > Sent: Sat, 12 Dec 2020 14:25
>>
>> > > > To: discuss@lists.openscad.org
>>
>> > > > Subject: Re: [OpenSCAD] 2020.12-RC2 bogus model does not give CGAL
>> error
>>
>> > > >
>>
>> > > > I didn't even think of possible lazy union here. I know that lazy
>> union is
>>
>> > > > enabled for my RC---I previously tested this. And yes, I did turn
>> it on in
>>
>> > > > a snapshot, so that seems to explain why.
>>
>> > > >
>>
>> > > > I wrapped with a union() and then I get a CGAL error as expected.
>>
>> > > >
>>
>> > > > What happens with lazy union if you don't union the top level
>> items? I took
>>
>> > > > my bad (?) file (without the top level union) and saved an STL and
>> my slicer
>>
>> > > > seemed happy. (But I don't have the various mesh analysis tools
>> everybody
>>
>> > > > uses to figure out just how bad the STL might be. Maybe
>> PrusaSlicer is
>>
>> > > > really good at repairing/interpreting bad inputs.)
>>
>> > > >
>>
>> > > >
>>
>> > > > MichaelAtOz wrote
>>
>> > > > > Windows 7, I get CGAL errors on both 2019.05 & RC2.
>>
>> > > > >
>>
>> > > > > I get different console output.
>>
>> > > > > On 2019.05, similar to Adrian's, but with the CGAL error after
>> 'Rendering
>>
>> > > > > Polygon Mesh using
>>
>> > > > > CGAL...'.
>>
>> > > > >
>>
>> > > > > RC2 is truncated:
>>
>> > > > >
>>
>> > > > > Parsing design (AST generation)...
>>
>> > > > > Compiling design (CSG Tree generation)...
>>
>> > > > > Rendering Polygon Mesh using CGAL...
>>
>> > > > > ERROR: CGAL error in CGALUtils::applyUnion3D: CGAL ERROR:
>> assertion
>>
>> > > > > violation! Expr:
>>
>> > > > > G.mark(v1,0)==G.mark(v2,0)&& G.mark(v1,1)==G.mark(v2,1) File:
>>
>> > > > >
>> /mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_S2/SM_overlayer.h
>>
>> > > > > Line: 303, location
>>
>> > > > > unknown
>>
>> > > > > UI-WARNING: No top level geometry to render location unknown
>>
>> > > > >
>>
>> > > > > i.e no cache stats or time.
>>
>> > > > >
>>
>> > > > > Adrian, see https://github.com/openscad/openscad/issues/3517
>>
>> > > > > Did you use a snapshot to test Lazy-Union?
>>
>> > > > >
>>
>> > > > > Wrap the path_sweep & cube in a union.
>>
>> > > > >
>>
>> > > > >> -----Original Message-----
>>
>> > > > >> From: Discuss [mailto:
>>
>> > > >
>>
>> > > > > discuss-bounces@.openscad
>>
>> > > >
>>
>> > > > > ] On Behalf Of adrianv
>>
>> > > > >> Sent: Sat, 12 Dec 2020 12:00
>>
>> > > > >> To:
>>
>> > > >
>>
>> > > > > discuss@.openscad
>>
>> > > >
>>
>> > > > >> Subject: [OpenSCAD] 2020.12-RC2 bogus model does not give CGAL
>> error
>>
>> > > > >>
>>
>> > > > >> I wrote the code below to help a user on another thread, but I
>> noticed a
>>
>> > > > >> weird thing. With the parameters below, the sweep gives a bad
>> polyhedron
>>
>> > > > >> with self-intersections. And yet, with the RC I do not get a
>> CGAL error,
>>
>> > > > >> at
>>
>> > > > >> least under Linux. With 2019.05 I do get a CGAL error, but
>> under the
>>
>> > > > >> RC:
>>
>> > > > >>
>>
>> > > > >> Parsing design (AST generation)...
>>
>> > > > >> Compiling design (CSG Tree generation)...
>>
>> > > > >> Rendering Polygon Mesh using CGAL...
>>
>> > > > >> Geometries in cache: 7
>>
>> > > > >> Geometry cache size in bytes: 1662680
>>
>> > > > >> CGAL Polyhedrons in cache: 0
>>
>> > > > >> CGAL cache size in bytes: 0
>>
>> > > > >> Total rendering time: 0:00:00.582
>>
>> > > > >> Top level object is a list of objects:
>>
>> > > > >> Objects: 2
>>
>> > > > >> Rendering finished.
>>
>> > > > >>
>>
>> > > > >>
>>
>> > > > >> include<BOSL2/std.scad>
>>
>> > > > >> include<BOSL2/skin.scad>
>>
>> > > > >>
>>
>> > > > >> $fn=16;
>>
>> > > > >> ofs = 1;
>>
>> > > > >> r=4;
>>
>> > > > >> number=5;
>>
>> > > > >> radius=1.4;
>>
>> > > > >>
>>
>> > > > >> path = [for(i=[0:2:359]) (r+ofs*sin(number*i))*[cos(i),sin(i)]];
>>
>> > > > >> path_sweep(circle(r=radius), path, closed=true);
>>
>> > > > >> cube(8);
>>
>> > > > >>
>>
>> > > > >>
>>
>> > > > >> I've also noticed that the RC doesn't always print blank lines
>> before
>>
>> > > > >> starting a new computation, which can make it hard to read the
>> output.
>>
>> > > > >>
>>
>> > > > >>
>>
>> > > > >>
>>
>> > > > >>
>>
>> > > > >> --
>>
>> > > > >> Sent from: http://forum.openscad.org/
>>
>> > > > >>
>>
>> > > > >> _______________________________________________
>>
>> > > > >> OpenSCAD mailing list
>>
>> > > > >>
>>
>> > > >
>>
>> > > > > Discuss@.openscad
>>
>> > > >
>>
>> > > > >>
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>> > > > >
>>
>> > > > >
>>
>> > > > > --
>>
>> > > > > This email has been checked for viruses by AVG.
>>
>> > > > > https://www.avg.com
>>
>> > > > >
>>
>> > > > >
>>
>> > > > > _______________________________________________
>>
>> > > > > OpenSCAD mailing list
>>
>> > > >
>>
>> > > > > Discuss@.openscad
>>
>> > > >
>>
>> > > > >
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>> > > >
>>
>> > > >
>>
>> > > >
>>
>> > > >
>>
>> > > >
>>
>> > > > --
>>
>> > > > Sent from: http://forum.openscad.org/
>>
>> > > >
>>
>> > > > _______________________________________________
>>
>> > > > OpenSCAD mailing list
>>
>> > > > Discuss@lists.openscad.org
>>
>> > > >
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>> > >
>>
>> > >
>>
>> > > --
>>
>> > > This email has been checked for viruses by AVG.
>>
>> > > https://www.avg.com
>>
>>
>> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free.
>> www.avg.com
>> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>> <#m_3614747264587405861_m_2570480591202271868_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>> _______________________________________________
>> OpenSCAD mailing list
>> Discuss@lists.openscad.org
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
A
arnholm@arnholm.org
Sat, Dec 12, 2020 9:31 AM
On 2020-12-12 10:12, nop head wrote:
I don't think OpenSCAD should export STLs with overlapping volumes.
Indeed, there is no concept of "volume" in STL files, so it is the same
as exporting a self-intersecting "non-manifold in need of repair" to use
OpenSCAD terminology. STL files contain a "soup" of triangles, nothing
else. The only meaningful way to properly export overlapping volumes to
STL would be to export each volume to a separate STL file.
Alternatively, use another export format with the ability to store
multiple volumes independent from each other.
Since OpenSCAD prefers to import STL files, a test of validity of an STL
export would be whether it could be imported again by OpenSCAD, i.e. the
typical round-trip test. I suppose it would always fail for "STLs with
overlapping volumes".
Carsten Arholm
On 2020-12-12 10:12, nop head wrote:
> I don't think OpenSCAD should export STLs with overlapping volumes.
Indeed, there is no concept of "volume" in STL files, so it is the same
as exporting a self-intersecting "non-manifold in need of repair" to use
OpenSCAD terminology. STL files contain a "soup" of triangles, nothing
else. The only meaningful way to properly export overlapping volumes to
STL would be to export each volume to a separate STL file.
Alternatively, use another export format with the ability to store
multiple volumes independent from each other.
Since OpenSCAD prefers to import STL files, a test of validity of an STL
export would be whether it could be imported again by OpenSCAD, i.e. the
typical round-trip test. I suppose it would always fail for "STLs with
overlapping volumes".
Carsten Arholm
JB
Jordan Brown
Sat, Dec 12, 2020 4:45 PM
On 12/12/2020 1:12 AM, nop head wrote:
I don't think OpenSCAD should export STLs with overlapping volumes.
Concur.
I haven't really been following the "lazy union" feature. I'd gotten
the impression that it was a performance optimization. If that's true,
the end result needs to be the same as before the optimization -
suggesting a final union of the top-level objects.
On 12/12/2020 1:12 AM, nop head wrote:
> I don't think OpenSCAD should export STLs with overlapping volumes.
Concur.
I haven't really been following the "lazy union" feature. I'd gotten
the impression that it was a performance optimization. If that's true,
the end result needs to be the same as before the optimization -
suggesting a final union of the top-level objects.
A
adrianv
Sat, Dec 12, 2020 5:04 PM
No, lazy union is more than a performance optimization. It leads to a major
language change where unions don't occur unless you request them. So for
example, you would be able to run a for() and access each iteration of the
for() as a child instead of having it automatically unioned.
At the moment I'm not sure exactly when the unions happen. I know
difference() produces different results with lazy union, but user defined
modules still get the implied union. So for example, if you do
difference() for(x=[1,2,3]) thing(x);
then without lazy union difference has one child and you get the union of
thing(1), thing(2) and thing(3) as the result. With lazy union, difference
has 3 children and you get thing(1) with thing(2) and thing(3) subtracted.
JordanBrown wrote
On 12/12/2020 1:12 AM, nop head wrote:
I don't think OpenSCAD should export STLs with overlapping volumes.
Concur.
I haven't really been following the "lazy union" feature. I'd gotten
the impression that it was a performance optimization. If that's true,
the end result needs to be the same as before the optimization -
suggesting a final union of the top-level objects.
OpenSCAD mailing list
No, lazy union is more than a performance optimization. It leads to a major
language change where unions don't occur unless you request them. So for
example, you would be able to run a for() and access each iteration of the
for() as a child instead of having it automatically unioned.
At the moment I'm not sure exactly when the unions happen. I know
difference() produces different results with lazy union, but user defined
modules still get the implied union. So for example, if you do
difference() for(x=[1,2,3]) thing(x);
then without lazy union difference has one child and you get the union of
thing(1), thing(2) and thing(3) as the result. With lazy union, difference
has 3 children and you get thing(1) with thing(2) and thing(3) subtracted.
JordanBrown wrote
> On 12/12/2020 1:12 AM, nop head wrote:
>> I don't think OpenSCAD should export STLs with overlapping volumes.
>
> Concur.
>
> I haven't really been following the "lazy union" feature. I'd gotten
> the impression that it was a performance optimization. If that's true,
> the end result needs to be the same as before the optimization -
> suggesting a final union of the top-level objects.
>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@.openscad
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
--
Sent from: http://forum.openscad.org/
JB
Jordan Brown
Sat, Dec 12, 2020 5:10 PM
On 12/12/2020 9:04 AM, adrianv wrote:
No, lazy union is more than a performance optimization. It leads to a major
language change where unions don't occur unless you request them. So for
example, you would be able to run a for() and access each iteration of the
for() as a child instead of having it automatically unioned.
As Emily Litella would say, "Oh, that's very different. Never mind".
(But I have to wonder how it interacts with $children.)
On 12/12/2020 9:04 AM, adrianv wrote:
> No, lazy union is more than a performance optimization. It leads to a major
> language change where unions don't occur unless you request them. So for
> example, you would be able to run a for() and access each iteration of the
> for() as a child instead of having it automatically unioned.
As Emily Litella would say, "Oh, that's very different. Never mind".
(But I have to wonder how it interacts with $children.)
HL
Hans L
Sat, Dec 12, 2020 6:24 PM
Before the whole discussion gets too carried away regarding lazy union, I
want to point out that the feature it's still incomplete and experimental,
and NOT intended to be enabled (nor enableable) in the RC.
There was a bug where experimental feature settings from snapshots could be
picked up by non-experimental builds, but it should be fixed in latest
master (I think just not in RC2, but should be the next RC revision):
https://github.com/openscad/openscad/issues/3517
On Sat, Dec 12, 2020 at 11:11 AM Jordan Brown openscad@jordan.maileater.net
wrote:
On 12/12/2020 9:04 AM, adrianv wrote:
No, lazy union is more than a performance optimization. It leads to a major
language change where unions don't occur unless you request them. So for
example, you would be able to run a for() and access each iteration of the
for() as a child instead of having it automatically unioned.
As Emily Litella would say, "Oh, that's very different. Never mind".
(But I have to wonder how it interacts with $children.)
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Before the whole discussion gets too carried away regarding lazy union, I
want to point out that the feature it's still incomplete and experimental,
and NOT intended to be enabled (nor enableable) in the RC.
There was a bug where experimental feature settings from snapshots could be
picked up by non-experimental builds, but it should be fixed in latest
master (I think just not in RC2, but should be the next RC revision):
https://github.com/openscad/openscad/issues/3517
On Sat, Dec 12, 2020 at 11:11 AM Jordan Brown <openscad@jordan.maileater.net>
wrote:
> On 12/12/2020 9:04 AM, adrianv wrote:
>
> No, lazy union is more than a performance optimization. It leads to a major
> language change where unions don't occur unless you request them. So for
> example, you would be able to run a for() and access each iteration of the
> for() as a child instead of having it automatically unioned.
>
>
> As Emily Litella would say, "Oh, that's very different. Never mind".
>
> (But I have to wonder how it interacts with $children.)
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
