
12

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. 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
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


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. 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
_______________________________________________
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
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 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():
polygon([ [2,2],[3,3], [2,4] ]); translate([1,0]) square(2);
_______________________________________________
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. 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
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


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 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
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


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. 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
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


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


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


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 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
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


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:
> 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
_______________________________________________
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. 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:
> 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
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


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


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:
> 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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

12
