avoiding assertion violation

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

avoiding assertion violation

DanS

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_64-w64-mingw32.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
Reply | Threaded
Open this post in threaded view
|

Re: avoiding assertion violation

MichaelAtOz
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.2099-thick], [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 [5-0.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!
Reply | Threaded
Open this post in threaded view
|

Re: avoiding assertion violation

Ronaldo
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 self-intersection 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,
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.2099-thick], [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 [5-0.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
Reply | Threaded
Open this post in threaded view
|

Re: avoiding assertion violation

DanS
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 Y-axis. 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,
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.2099-thick], [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 [5-0.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
Reply | Threaded
Open this post in threaded view
|

Re: avoiding assertion violation

MichaelAtOz
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!
Reply | Threaded
Open this post in threaded view
|

Re: avoiding assertion violation

Ronaldo
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 non-manifold 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 non-manifoldness 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 non-manifoldness of rotate_extrude():

rotate_extrude(){
  polygon([ [2,2],[3,3], [2,4] ]);
  translate([1,0]) square(2);
}
cube();

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: avoiding assertion violation

MichaelAtOz
Administrator
Ronaldo wrote

> In the limit case, when just a simple polygon vertex is on the Y axis,
> there is no smartness to avoid non-manifoldness 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 non-manifoldness 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!
Reply | Threaded
Open this post in threaded view
|

Re: avoiding assertion violation

nophead
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
> In the limit case, when just a simple polygon vertex is on the Y axis,
> there is no smartness to avoid non-manifoldness 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 non-manifoldness 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
Reply | Threaded
Open this post in threaded view
|

Re: avoiding assertion violation

cacb
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 non-manifold 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), self-intersection and collapsed faces is about
geometry (coordinates in this case). You can have a self-intersecting
polyhedron with collapsed faces which is 2 manifold, as in the below example

When you say "I would expect a non-manifold 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 non-manifold model and containing collapsed
faces. After repair, the collapsed faces are removed and thus the model
is again 2-manifold.

===
$ polyfix rotate1.off

Parameters:
   input_file = rotate1.off


polyhedron 0 ================= volume=14.5942, dtol=0.01, atol=1e-06,
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 water-tight (edge use-count check OK)
 >>> Warning: Polyhedron has 1 zero area faces.
...Polyhedron has 15 non-triangular 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=1e-06,
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
Reply | Threaded
Open this post in threaded view
|

Re: avoiding assertion violation

nophead
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:
> 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 non-manifold 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), self-intersection and collapsed faces is about
geometry (coordinates in this case). You can have a self-intersecting
polyhedron with collapsed faces which is 2 manifold, as in the below example

When you say "I would expect a non-manifold 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 non-manifold model and containing collapsed
faces. After repair, the collapsed faces are removed and thus the model
is again 2-manifold.

===
$ polyfix rotate1.off

Parameters:
   input_file = rotate1.off


polyhedron 0 ================= volume=14.5942, dtol=0.01, atol=1e-06,
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 water-tight (edge use-count check OK)
 >>> Warning: Polyhedron has 1 zero area faces.
...Polyhedron has 15 non-triangular 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=1e-06,
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
Reply | Threaded
Open this post in threaded view
|

Re: avoiding assertion violation

Parkinbot
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
> self-intersection 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 y-half 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 XY-plane
{
  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
Reply | Threaded
Open this post in threaded view
|

Re: avoiding assertion violation

nophead
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
>  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
> self-intersection 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 y-half 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 XY-plane
{
  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
Reply | Threaded
Open this post in threaded view
|

Re: avoiding assertion violation

cacb
In reply to this post by nophead
On 2019-07-17 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
1-manifold 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
Reply | Threaded
Open this post in threaded view
|

Re: avoiding assertion violation

nophead
How does it differ from the OP's?

On Wed, 17 Jul 2019 at 13:53, <[hidden email]> wrote:
On 2019-07-17 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
1-manifold 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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: avoiding assertion violation

cacb
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 Y-axis 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 OpenSCAD-generated model into AngelCAD
(OFF-version) 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=1e-06,
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
Reply | Threaded
Open this post in threaded view
|

Re: avoiding assertion violation

nophead
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:
> How does it differ from the OP's?

We might perhaps know if the source is posted.

The claim that touching the Y-axis 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 OpenSCAD-generated model into AngelCAD
(OFF-version) 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=1e-06,
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
Reply | Threaded
Open this post in threaded view
|

Re: avoiding assertion violation

DanS
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);
}

Virus-free. www.avast.com

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 Y-axis 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 OpenSCAD-generated model into AngelCAD
(OFF-version) 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=1e-06,
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
Reply | Threaded
Open this post in threaded view
|

Re: avoiding assertion violation

nophead
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 non-zero thickness.

On Wed, 17 Jul 2019 at 15:34, Dan Shriver <[hidden email]> wrote:
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);
}

Virus-free. www.avast.com

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 Y-axis 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 OpenSCAD-generated model into AngelCAD
(OFF-version) 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=1e-06,
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
Reply | Threaded
Open this post in threaded view
|

Re: avoiding assertion violation

Parkinbot
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
Reply | Threaded
Open this post in threaded view
|

Re: avoiding assertion violation

bboett
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:
> 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 non-manifold 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), self-intersection and collapsed faces is about
geometry (coordinates in this case). You can have a self-intersecting
polyhedron with collapsed faces which is 2 manifold, as in the below example

When you say "I would expect a non-manifold 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 non-manifold model and containing collapsed
faces. After repair, the collapsed faces are removed and thus the model
is again 2-manifold.

===
$ polyfix rotate1.off

Parameters:
   input_file = rotate1.off


polyhedron 0 ================= volume=14.5942, dtol=0.01, atol=1e-06,
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 water-tight (edge use-count check OK)
 >>> Warning: Polyhedron has 1 zero area faces.
...Polyhedron has 15 non-triangular 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=1e-06,
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


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