@Carsten
silent repairs are nice (and an essential part of the one an only
do_what_I_mean() function), but usually you open a can of worms with it. It
is obvious (with reference to F12) that triags with false orientation can be
identified and reversed. But this is only the tip of the iceberg.

@Marius
this is your minimal code example for this theme. It shows that
linear_extrude() itself does not test for selfintersection. So without a
Boolean operation (= commenting the first line out) you even don't get a
warning and can do an ill-formed STL export. Consequently it might be a good
idea to implement at least a warning for polygon():

--
View this message in context: http://forum.openscad.org/An-alternative-to-linear-extrude-tp19503p19524.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

So are loops only a problem for the volume of space at the intersection, or
do loops inherently generate problems over their whole length (if so is
that the case only if the loop is inside the larger polygon, or even if it
is outside)?  I ask because the functions I created in that program are
fractal in nature.  They don't just generate a single loop (like the large
one in the interior at the "cardiod" like point) but as the generations go
on more and more loops are created here and there.

For a background on these shapes and a simple example of what some
generations look like see the following:

http://www.mathrecreation.com/2009/08/hypocycloid-scrambler.html
http://www.mathrecreation.com/2009/09/scrambler-fractal.html

My program basically generates each generation and "the space in between".
That is on each successive generation I add a circle and it grows from
almost nothing to something half the size of the previous circle.

Not sure if it is gmail or this list... but one early replier said they had
a picture and I didn't see any picture in that reply.

I think that my "inside out" faces were all (or most) healed when I ran my
STL through meshmixer which has an automatic "fix problems" function.  Of
course, it could have fixed problems at the cost of obscuring details.

My biggest issues were that the time to generate my shapes was
astronomical.  I would plot out 4-5 generations in something like 8-12
hours of computing time.  Also my program tries to make a nice continuous
shape by exactly transposing each generation so it touches with the
previous generation.  However on later generations I found that there were
tiny gaps between them.  This could be some floating point error problem...
I couldn't figure out why they happened.

On Sat, Dec 10, 2016 at 7:03 AM, Parkinbot rudolf@parkinbot.com wrote:

On 10. des. 2016 13:03, Parkinbot wrote:

As mentioned before, the intent is orthogonal to any idea of
"do_what_I_mean()". No software can do such a thing, and instead mine
checks/corrects against a set of well defined rules dictated by the
requirements of boolean operations.

There are some things such techniques can do and some things it cannot
do. Maybe that is a can of worms, I don't know, but I think it is true
for almost any software. If it helps in a large number of cases I think
it makes a lot of sense.

Presenting back sides of triangles in a graphical presentation is is
trivial, it requires no analysis at all. To identify and reverse the
triangles in algorithms is a different matter, but yes it can be done.

There are a number of aspects involved, and many common problems can be
corrected automatically.

Carsten Arnholm

DanS,

The rules for getting proper 3D objects are:

1. use non self-intersecting polygons
2. create proper manifolds.
   If you stick to that two rules your code will be ok. But please don't expect
   recursive code to obey to that rules nor OpenSCAD to test for it.

If you do an 8, your polygon will change its orientation at the crossing
turning inside to outside and vice versa. As polygon() does not seem to
check for this, linear_extrude() creates non-manifolds.
If you

Your time problem is a different effect. It is the high number of (implicit)
unions you are using.

Have a look at this code example, which properly deals with the loop:

--
View this message in context: http://forum.openscad.org/An-alternative-to-linear-extrude-tp19503p19535.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Parkinbot wrote

and this is how you fix it:
cube(4, center = true);
linear_extrude(height=10) polygon([[-10,-10], [-10,10],[0,.0001],
[10,10],[10,-10],[0,-.0001]]);

Just remember: OpenSCAD uses a mesh to represent geometry. If you construct
your mesh badly, you will generate problems. The reverse is also true: If
you construct the mesh well, you won't have problems. And also remember:
OpenSCAD generates the warning about non-manifoldness every time two
polygons touch on one edge. In this case, generating two trigonal prisms
touching on one edge, not, as is claimed, self-intersections.
True self-intersections exhibit inside-out faces on one half of a face,
outside-in faces on the other half. Parkinbot's example just fools OpenSCAD.

wolf

--
View this message in context: http://forum.openscad.org/An-alternative-to-linear-extrude-tp19503p19568.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

What happens here can be a bit non-obvious:
The 2D input polygon is self-intersecting. We implicitly repair this self-intersection using an “odd winding rule”. The resulting 2D object is two triangles touching in one vertex. We perform the linear extrude on these two triangles.

At this point we’re perfectly aware that the linear extrude is performed on two separate objects, but we don’t actively split them up and thus don’t have a way of providing this as a valid input to CGAL.

We could improve this particular case, but due to non-manifold objects having severe issues both upstream and downstream from this isolated example I’m not sure it’s worth spending time on right now.

-Marius

kintel wrote

I would go a little further. To be consistent with the 3D stuff, 2D polygon
self-intersection should rise a qualified error.

And regarding issue  591 https://github.com/openscad/openscad/issues/591
: a few months ago, I provocatively suggested the use of 0 scale with
Minkovsky and hull as a modelling tool and it was strongly rejected; why 0
scale in linear_extrude is considered a reasonable modelling resource?

--
View this message in context: http://forum.openscad.org/An-alternative-to-linear-extrude-tp19503p19572.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

For user input that makes sense.
Note, however, that we probably need to be robust when processing things like plane intersections or projections due to rounding from Gmpq to float. ..which is why we have a robust code path.

For hulls it makes sense to do this, as we don’t have point primitives. We also don’t have a good way of passing around geometry scaled by zero (as all polygons are then gone), so this isn’t something we can just “turn on”.
Feel free to raise a github issue on this - it’s hard to track suggestions from mailing list threads.

-Marius