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/

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@lists.openscad.org] On Behalf Of adrianv > Sent: Sat, 12 Dec 2020 12:00 > To: discuss@lists.openscad.org > 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@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

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&lt;BOSL2/std.scad&gt; >> include&lt;BOSL2/skin.scad&gt; >> >> $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/