I am getting: ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion violation! Expr: e>incident_sface() != SFace_const_handle() File: /opt/mxe/usr/x86_64w64mingw32.static.posix/include/CGAL/Nef_S2/SM_const_decorator.h Line: 329 And I am wondering what I should do to avoid it. If I want to take a 3D shape and make another 3D shape by transposing it so it overlaps itself (and other shapes) do I have to do a "union () {}" operation over all of them to clean up intersections between the shapes? I tried it with and without the union and still get the exception. I don't think my points are particularly close together. They would be: [0, 73.2099] [1, 72.66682] [2, 70.4477] [3, 64.1422] [4, 46.9017] [5, 0] most of the y values are probably irrational but I don't think they are "too close" (maybe I'm wrong). I make a polygon with this and then do rotate extrude and scale it [8,8,1] and [8,12,1] I am making a catenoidal dome so it is kind of hard for me to avoid irrational numbers _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
Administrator

If you don't do a union, OpenSCAD does it implicitly, at various places,
including a global one. Union() does not 'clean up', it just joins objects, if they touch properly. Don't focus too much on the irrational number issue. Those points are fine in themselves. Such CGAL errors tend to come from interactions between objects. But in this case it comes from the rotate_extrude. rotate_extrude(angle=360) { tip=0; // 0.0001; polygon(points=[ [tip, 73.2099], [1, 72.66682], [2, 70.4477], [3, 64.1422], [4, 46.9017], [5, 0] ]); } cube(); // test for CGAL issues With tip=0 it gets the CGAL error, I initially suspected it may be a bug. At first glance I would expect it to be able to make such a shape. The problem is the tip forms what I call a singularity. If you look at a sphere it doesn't have such a convergence point. There have been similar problems with a torus which meets in the middle. However, I think the problem is at the tip it is infinitely thin. So CGAL can't tell the difference between the top surface and the inside surface. A fix is to add a point along the centre axis jut below the tip to provide thickness. rotate_extrude(angle=360) { thick=0.2; // this value is a design choice you should make polygon(points=[ [0, 73.2099thick], [0, 73.2099], [1, 72.66682], [2, 70.4477], [3, 64.1422], [4, 46.9017], [5, 0] ]); } cube(1); // test for CGAL issues That works. While the base doesn't produce a error, having the taper down to a fine point is probably asking for trouble. So I'd also suggest adding a point like [50.001, 0] on the end so it isn't approaching infinitely thin.  Admin  email* me if you need anything, or if I've done something stupid... * click on my MichaelAtOz label, there is a link to email me. Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above. The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!  Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Admin  email* me if you need anything,
or if I've done something stupid... * click on my MichaelAtOz label, there is a link to email me. Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above. The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out! 
In some sense this is a bug of rotate_extrude(). OpenScad complains when some edge of the polygon crosses the Y Axis because that would generate a selfintersection 3D object. The current case is a limit case of the forbiden crossing and OpenScad should issue an error as well. A terça, 16/07/2019, 21:02, MichaelAtOz <[hidden email]> escreveu: If you don't do a union, OpenSCAD does it implicitly, at various places, _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
In reply to this post by MichaelAtOz
Thanks guys.  If it's not my bug but is a kind of error in rotate_extrude I suggest 2 things:1) in the documentation for rotate_extrude mention that all points must be >0 for y value. The documentation I saw mentions it in a way that if you are skimming through you don't notice right away "The 2D shape needs to lie completely on either the right (recommended) or the left side of the Yaxis. More precisely speaking, each vertex of the shape must have either x >= 0 or x <= 0. If the shape crosses" I think it would be more clear if the y instructions were written in a similar vein to the x instructions ("y>0, or y<0 for all vertices"). I tend to skim over things quickly and the x stuff jumps out whereas the y stuff just sort of disappears into the background 2) if the exception message was different, perhaps the code could check for a bad vertex and tell the user. It already seems to do that for x values. I know everyone is busy, I'm just thinking if these suggestions are put on a list they might get implemented at some point. On Tue, Jul 16, 2019 at 8:02 PM MichaelAtOz <[hidden email]> wrote: If you don't do a union, OpenSCAD does it implicitly, at various places, _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
Administrator

DanS wrote
> If it's not my bug but is a kind of error in rotate_extrude Well it sort of is your bug, you are asking CGAL to make something impossible. A zero thickness 3D object, at that single point at the top. What Ronaldo says is if there is a bug it would be that OpenSCAD might be able to detect such attempts and produce a better error message. I'll review the wiki tho, there may be a place for some tips.  Admin  email* me if you need anything, or if I've done something stupid... * click on my MichaelAtOz label, there is a link to email me. Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above. The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!  Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Admin  email* me if you need anything,
or if I've done something stupid... * click on my MichaelAtOz label, there is a link to email me. Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above. The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out! 
Em qua, 17 de jul de 2019 às 03:07, MichaelAtOz <[hidden email]> escreveu: What Ronaldo says is if there is a bug it would be that OpenSCAD might be The only situation the rotate_extrude() of a simple polygon is clearly a manifold is when the polygon does not have any intersection with the Y axis and it rests entirely at left or at right of the Y axis. Then the rotate_extrude() will be a torus like object. When the intersection of a simple polygon and the Y axis is a full polygon edge, I would expect a nonmanifold result because that particular edge would be in the interior of the object. But CGAL does produce a valid polyhedron which means, I suppose, that OpenSCAD smartly removes that offending edge before calling CGAL. Then, the rotate_extrude() will not be the union of torus like objects  it will not have a genus. In the limit case, when just a simple polygon vertex is on the Y axis, there is no smartness to avoid nonmanifoldness and an error might be issued. However, when, the polygon is not simple, like in the example bellow, it is harder to detect beforehand a nonmanifoldness of rotate_extrude():
_______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
Administrator

Ronaldo wrote
> In the limit case, when just a simple polygon vertex is on the Y axis, > there is no smartness to avoid nonmanifoldness and an error might be > issued. > > However, when, the polygon is not simple, like in the example bellow, it > is > harder to detect beforehand a nonmanifoldness of rotate_extrude(): > > rotate_extrude(){ > polygon([ [2,2],[3,3], [2,4] ]); > translate([1,0]) square(2); > } > cube(); So a test would be if polygon vertex.x=0 then at least one adjacent vertex must have x=0 & a different y.  Admin  email* me if you need anything, or if I've done something stupid... * click on my MichaelAtOz label, there is a link to email me. Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above. The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!  Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Admin  email* me if you need anything,
or if I've done something stupid... * click on my MichaelAtOz label, there is a link to email me. Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above. The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out! 
Yes that sounds right. Each bit that touches the y axis can't be a single point because that creates a singularity when rotated. The zero thickness knife edge at the bottom is dodgy as well. Any CGAL operations near that point are likely to create self intersections. Both features are psychically impossible. On Wed, 17 Jul 2019 at 07:43, MichaelAtOz <[hidden email]> wrote: Ronaldo wrote _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
In reply to this post by Ronaldo
On 17.07.2019 08:16, Ronaldo Persiano wrote:
> Em qua, 17 de jul de 2019 às 03:07, MichaelAtOz <[hidden email] > <mailto:[hidden email]>> escreveu: > > What Ronaldo says is if there is a bug it would be that OpenSCAD > might be > able to detect such attempts and produce a better error message. > > > The only situation the rotate_extrude() of a simple polygon is clearly a > manifold is when the polygon does not have any intersection with the Y > axis and it rests entirely at left or at right of the Y axis. Then the > rotate_extrude() will be a torus like object. > > When the intersection of a simple polygon and the Y axis is a full > polygon edge, I would expect a nonmanifold result because that > particular edge would be in the interior of the object. But CGAL does > produce a valid polyhedron I don't know how rotate_extrude is implemented in OpenSCAD, but I am guessing CGAL does not provide such a feature, and instead rotate_extrude is done by OpenSCAD directly to compute the coordinates of a polyhedron. Implemented this way, there are no boolean operations involved. This is certainly the case in AngelCAD where rotate_extrude is not a feature at all in Carve (Carve is the equivalent to CGAL), it is computed directly by the application, not the library. The implication is that the issue is not about manifoldness, but rather about self intersection and collapsed faces. Manifoldness is about topology (connectivity), selfintersection and collapsed faces is about geometry (coordinates in this case). You can have a selfintersecting polyhedron with collapsed faces which is 2 manifold, as in the below example When you say "I would expect a nonmanifold result because that particular edge would be in the interior of the object. But CGAL does produce a valid polyhedron". I would say CGAL that is correct, and the expectation is incorrect. Consider the example rotate_extrude(){ polygon([ [0,2],[2,0], [0,2] ]); } This produces no error by OpenSCAD, and you could argue it is ok at this stage. Top level object is a 3D object: Facets: 42 The visible external faces are only 14. If you export to OFF format and then analyze it with polyfix... OFF export finished: O:/STL/rotate1.off ...you will find that OpenSCAD appears to have merged overlapping vertices, thus creating a nonmanifold model and containing collapsed faces. After repair, the collapsed faces are removed and thus the model is again 2manifold. === $ polyfix rotate1.off Parameters: input_file = rotate1.off polyhedron 0 ================= volume=14.5942, dtol=0.01, atol=1e06, maxiter=10 iteration 0: vertices=9 faces=42 warning: 28 zero area faces. warning: nonmanifold edges: uc(4)=14 uc(14)=2 uc(28)=1 removed 28 collapsed or zero area faces total changes=28 no warnings iteration 1: vertices=9 faces=14 total changes=0 no warnings Summary: polyhedron 0: vertices=9 faces=14 : no warnings Writing: rotate1_1.off === We can repeat the same exercise in AngelCAD (coordinates are a bit different, because AngelCAD rotates around global Y). // AngelCAD code. shape@ main_shape() { array<pos2d@> p = { {0,2},{2,0},{0,2} }; return rotate_extrude(polygon(p),deg:360); } void main() { shape@ obj = main_shape(); obj.write_xcsg(GetInputFullPath(),secant_tolerance:0.2); } This creates the output xcsg processing: /media/nas_openbzr/STL/xcsg/test1.xcsg processing solid: rotate_extrude ...completed CSG tree: 0 boolean operations to process. ...Info: rotate_extrude angle>=2*PI implies a torus ...completed boolean operations in 0 [sec] ...result model contains 1 lump. ...lump 1: 21 vertices, 15 polygon faces. ...Polyhedron is watertight (edge usecount check OK) >>> Warning: Polyhedron has 1 zero area faces. ...Polyhedron has 15 nontriangular faces ...Triangulating lump ... ...Triangulation completed with 28 triangle faces in 0 [sec] ...Exporting results Created STL file : /media/nas_openbzr/STL/xcsg/test1.stl xcsg finished using 0h 0m 0.01s i.e. 28 faces makes sense = 7x3, of which one third will be collapsed, due to the way rotate_extrude is implemented. ===== $ polyfix xcsg/test1.off Parameters: input_file = xcsg/test1.off polyhedron 0 ================= volume=14.5942, dtol=0.01, atol=1e06, maxiter=10 iteration 0: vertices=21 faces=28 warning: 14 zero area faces. warning: nonmanifold edges: uc(1)=14 merged 12 vertices removed 14 collapsed or zero area faces total changes=26 no warnings iteration 1: vertices=9 faces=14 total changes=0 no warnings Summary: polyhedron 0: vertices=9 faces=14 : no warnings Writing: xcsg/test1_1.off ===== Here, polyfix assumes overlapping vertices is undesired and merges them, the end result is the same as via OpenSCAD, 14 faces and 9 vertices. Carsten Arnholm _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
I think rotate extrude does its work in PolySets which, just like STL, is a polygon soup and cannot represent a 2 manifold with self intersections. Then when that is given to CGAL it barfs. Since OpenSCAD is aimed at 3D printing and nearly all output is via STL it gets away with using PolySets and should give an error message for geometry with self intersections. If an output format other than STL ever becomes popular and people wanted to export self intersection geometry OpenSCAD would have to be rewritten to not use PolySets. I don't really see the point as such geometry only exists in maths, not in physical reality. On Wed, 17 Jul 2019 at 12:31, Carsten Arnholm <[hidden email]> wrote: On 17.07.2019 08:16, Ronaldo Persiano wrote: _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
In reply to this post by Ronaldo
Ronaldo wrote
> In some sense this is a bug of rotate_extrude(). OpenScad complains when > some edge of the polygon crosses the Y Axis because that would generate a > selfintersection 3D object. The current case is a limit case of the > forbiden crossing and OpenScad should issue an error as well. It would be a progress to have a procrusting rotate_extrude() which performs an (internal) intersection with the positive yhalf of the XY plane on its operands. This would eliminate at least some of the strange rotate_extrude() issues. Another (natural) semantics would be to cut the operand into two halfs, rotate them separately, and union the results. Here an implementation which I meanwhile use in my shortcuts.scad library: Re() polygon([ [0,2], [10,1.3],[2.5,0],[3,3], [2,4]]); // Re2() polygon([ [0,2], [10,1.3],[2.5,0],[3,3], [2,4]]); cube(); module Re(angle = 360) // procrust operand to half XYplane { rotate_extrude(angle = angle) intersection() { translate([0, 1e5])square([1e5, 2e5]); children(); } } module Re2(angle = 360) // allow for all operands { rotate_extrude(angle = angle) intersection() { translate([1e10, 0])square([2e10, 1e10], center = true); children(); } rotate_extrude(angle = angle) intersection() { translate([1e10, 0])square([2e10, 1e10], center = true); children(); } }  Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
This isn't about crossing the Y axis, it is about touching it at a single point. On Wed, 17 Jul 2019 at 13:16, Parkinbot <[hidden email]> wrote: Ronaldo wrote _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
In reply to this post by nophead
On 20190717 14:04, nop head wrote:
> I think rotate extrude does its work in PolySets which, just like STL, > is a polygon soup and cannot represent a 2 manifold with self > intersections. If so, that is a truism. In a polygon soup by definition you have only 1manifold edges. > Then when that is given to CGAL it barfs. It didn't in the case I showed. Carsten Arnholm _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
How does it differ from the OP's? On Wed, 17 Jul 2019 at 13:53, <[hidden email]> wrote: On 20190717 14:04, nop head wrote: _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
On 17.07.2019 15:23, nop head wrote:
> How does it differ from the OP's? We might perhaps know if the source is posted. The claim that touching the Yaxis in a single point is causing assertion when used in rotate_extrude can be tested: rotate_extrude(){ polygon([ [0,0],[2,2], [2,2] ]); } This works fine in OpenSCAD 2019.03.31 and it can be exported successfully to various formats, including OFF (sing1.off, vertices=15 faces=28) and STL (sing1.stl, vertices=84 faces=28). The assertion occurs in OpenSCAD if you try to union with a cube: rotate_extrude(){ polygon([ [0,0],[2,2], [2,2] ]); } cube(1); Or this way, it also gives an assertion import("./sing1.stl"); cube(1); Now, if you import the OpenSCADgenerated model into AngelCAD (OFFversion) and union it with a cube as above and save it as test2.off: // AngelCAD code. shape@ main_shape() { polyhedron p("./sing1.off"); return p + cube(1); } In this case there is no problem, it works fine as shown in enclosed PNG image, and === $ polyfix test2.off Parameters: input_file = test2.off polyhedron 0 ================= volume=29.4181, dtol=0.01, atol=1e06, maxiter=10 iteration 0: vertices=20 faces=38 total changes=0 no warnings Summary: polyhedron 0: vertices=20 faces=38 : no warnings ==== Therefore, the problem seen in OpenSCAD is not really in rotate_extrude, but how the model is interpreted when subject to union using CGAL. The same union using Carve works fine as should be expected. Carsten Arnholm _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org test2.png (19K) Download Attachment 
Rotate extrude and linear extrude, polygon, etc, all work outside CGAL with PolySets. Only when you need a CSG op is it converted to a Nef_Polyhedron and fed to CGAL, which then barfs as I stated. It doesn't accept self intersecting geometry. On Wed, 17 Jul 2019 at 15:00, Carsten Arnholm <[hidden email]> wrote: On 17.07.2019 15:23, nop head wrote: _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
In reply to this post by cacb
If you're asking me to post my source here it is: Notes: 1) coshPolygon is corrected to start at 0.0001 not 0 as it was originally 2) If you use coshPolygon2 OpenSCAD helpfully spits out a message saying not to have points on both sides of the Y axis. I was suggesting that maybe instead of the cryptic exception I got a message saying "Do not have any points X=0" would be nice. I am seeing that people are saying if you have two points X = 0 with different Y values that would work, but that seems like a weird case (as people mention zero thickness) 3) if you make one hypDome things are fine (with coshPolygon starting at x=0 as it did originally). However, multiple overlapping, or overlapping another object causes the cryptic exception  function echoit5(y,x) = echo(y,x) x; //debug function cosh(x) = (exp(x) + exp(x))/2; function coshPolygon(multiplier, power, domain, flip, steps) = let (flipValue = flip ? cosh( ( multiplier *(pow(domain,power))) ) : 0) [ for(i = [0.0001: (domain / steps) : domain]) [i, flipValue  cosh( ( multiplier *(pow(i,power))) )] ]; function coshPolygon2(multiplier, power, domain, flip, steps) = [ for(i = [domain: (2 * domain / steps) : domain]) [i, cosh( ( multiplier *(pow(i,power))) )] ]; module hypDome(multiplier = 1, power = 1, domain = 2, flip = true, steps = 10, facets = 20) { rotate_extrude($fn = facets) { polygon(echoit5("raw polygon",coshPolygon(multiplier, power, domain, flip, steps))); } } scale([8,8,1]) { hypDome(1,1,5,true,10, 20); } On Wed, Jul 17, 2019 at 10:00 AM Carsten Arnholm <[hidden email]> wrote: On 17.07.2019 15:23, nop head wrote: _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
I am seeing that people are saying if you have two points X = 0 with different Y values that would work, but that seems like a weird case (as people mention zero thickness) No it is not a weird case, it is the normal case to make something without a hole through the middle. When you have a single point meeting the Y axis then you end up with a object with a zero thickness point where its top and bottom surfaces meet. If you have pairs of adjacent points on the Y axis then you end of with a normal solid with a nonzero thickness. On Wed, 17 Jul 2019 at 15:34, Dan Shriver <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
In reply to this post by DanS
So your problem is clear. You try to rotate around a single vertex and get a
singularity. The following modification avoids this problem by introducing another point on the y axis and creating an edge on the y axis. function coshPolygon(multiplier, power, domain, flip, steps) = let (flipValue = flip ? cosh( ( multiplier *(pow(domain,power))) ) : 0) let (result = [for(i = [0.0001: (domain / steps) : domain]) [i, flipValue  cosh( ( multiplier *(pow(i,power))) )] ]) concat(result, [[0, result[len(result)1][1]]]);  Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
In reply to this post by cacb
heh happily swimming in my ignorance and incompetence...... still..... you mention a tool polyfix that repairs the stl?? some pointer please? thanks! Bruno Am Mi., 17. Juli 2019 um 13:31 Uhr schrieb Carsten Arnholm <[hidden email]>: On 17.07.2019 08:16, Ronaldo Persiano wrote:  ciao Bruno =========================================== http://nohkumado.eu/, http://aikido.nohkumado.eu/, http://aikido.zorn.free.fr _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
Free forum by Nabble  Edit this page 