discuss@lists.openscad.org

OpenSCAD general discussion Mailing-list

View all threads

Polyhedron tube with irregular sides -- is it possible ?

N
NateTG
Mon, Jan 21, 2019 10:20 PM

cacb wrote

...
Why this long and complex discussion when you can use 2D booleans - i.e.
subtract the holes from the main rectangle and simply extrude that?

What is missing in this thinking?
...

I wanted to do 'wrap text on surface' stuff.  To make that work involves a
plastic transform, which, in OPENscad is only possible if you manipulate the
points as data.

https://gist.github.com/NateTG/b350378c56f436d3996a2107f7cba965

--
Sent from: http://forum.openscad.org/

cacb wrote > ... > Why this long and complex discussion when you can use 2D booleans - i.e. > subtract the holes from the main rectangle and simply extrude that? > > What is missing in this thinking? > ... I wanted to do 'wrap text on surface' stuff. To make that work involves a plastic transform, which, in OPENscad is only possible if you manipulate the points as data. https://gist.github.com/NateTG/b350378c56f436d3996a2107f7cba965 -- Sent from: http://forum.openscad.org/
N
NateTG
Mon, Jan 21, 2019 10:37 PM

Ronaldo wrote

I agree that earcut method may generate very bad triangles, almost
degenerated. That is one reason I would look for something else. I don't
know how the sweep line algorithms work but remind that for our
application
in mind we can't add new vertices to any polygonal.

You don't have to add vertices.  If you're sweeping "left to right" then it
will cut at every vertex that is "convex to the right."

It's basically this:

https://en.wikipedia.org/wiki/Polygon_triangulation#Monotone_Polygon_Triangulation

--
Sent from: http://forum.openscad.org/

Ronaldo wrote > I agree that earcut method may generate very bad triangles, almost > degenerated. That is one reason I would look for something else. I don't > know how the sweep line algorithms work but remind that for our > application > in mind we can't add new vertices to any polygonal. You don't have to add vertices. If you're sweeping "left to right" then it will cut at every vertex that is "convex to the right." It's basically this: https://en.wikipedia.org/wiki/Polygon_triangulation#Monotone_Polygon_Triangulation -- Sent from: http://forum.openscad.org/
A
arnholm@arnholm.org
Tue, Jan 22, 2019 8:14 AM

On 2019-01-21 21:59, Ronaldo Persiano wrote:

Why this long and complex discussion when you can use 2D booleans -
i.e.
subtract the holes from the main rectangle and simply extrude that?

The main goal now is to sweep a polygon with holes along a polygonal
line using fast polyhedron.

Maybe achieving something similar to this then?
https://gist.github.com/arnholm/931bba4633ca344a3ffe0698b945395f

This avoid slower boolean operations. As
Parkinbot pointed before, we might instead sweep the polygon border
and subtract the sweeping of each hole in a slower process.

Ok, but this should not really take a lot of processing time with any of
the possible approaches. The example above, which take a "high level
approach" instead of constructing a complex polyhedron manually, was
processed with https://github.com/arnholm/xcsg in less than 0.15 sec.

The 2d booleans are not slow in OpenSCAD, a built-in sweep is missing
though.

Carsten Arnholm

On 2019-01-21 21:59, Ronaldo Persiano wrote: > <arnholm@arnholm.org> wrote: > >> Why this long and complex discussion when you can use 2D booleans - >> i.e. >> subtract the holes from the main rectangle and simply extrude that? > > The main goal now is to sweep a polygon with holes along a polygonal > line using fast polyhedron. Maybe achieving something similar to this then? https://gist.github.com/arnholm/931bba4633ca344a3ffe0698b945395f > This avoid slower boolean operations. As > Parkinbot pointed before, we might instead sweep the polygon border > and subtract the sweeping of each hole in a slower process. Ok, but this should not really take a lot of processing time with any of the possible approaches. The example above, which take a "high level approach" instead of constructing a complex polyhedron manually, was processed with https://github.com/arnholm/xcsg in less than 0.15 sec. The 2d booleans are not slow in OpenSCAD, a built-in sweep is missing though. Carsten Arnholm
P
Parkinbot
Tue, Jan 22, 2019 12:36 PM

Carsten,

being able to extrude a 2D object (with holes) along a fancy path in
extension of linear_extrude would be a nice to have (without having to
install angelscript :-) ), but the discussed approach is even more
ambitious. Just read the thread from start.

The multi hole sweep will allow each polygon to morph along the path, like
shown in the following example code that "extrudes" a CW screw with a CCW
hole:

http://forum.openscad.org/file/t887/CWCCW.png

use <Naca_sweep.scad>
difference()
{
sweep(gendat(circle(100, N=4), 1));
sweep(gendat(circle(60, N=4), -.5));
}

function gendat(P, dir=1) =
[for (i=[-45:45]) Tz_(i, Rz_(dir*i, vec3D(P)))];

function circle(r, N) = [for(i=[0:N-1]) let(w=-360/Ni) r[cos(w), sin(w)]];

--
Sent from: http://forum.openscad.org/

Carsten, being able to extrude a 2D object (with holes) along a fancy path in extension of linear_extrude would be a nice to have (without having to install angelscript :-) ), but the discussed approach is even more ambitious. Just read the thread from start. The multi hole sweep will allow each polygon to morph along the path, like shown in the following example code that "extrudes" a CW screw with a CCW hole: <http://forum.openscad.org/file/t887/CWCCW.png> use <Naca_sweep.scad> difference() { sweep(gendat(circle(100, N=4), 1)); sweep(gendat(circle(60, N=4), -.5)); } function gendat(P, dir=1) = [for (i=[-45:45]) Tz_(i, Rz_(dir*i, vec3D(P)))]; function circle(r, N) = [for(i=[0:N-1]) let(w=-360/N*i) r*[cos(w), sin(w)]]; -- Sent from: http://forum.openscad.org/
A
arnholm@arnholm.org
Tue, Jan 22, 2019 2:21 PM

On 2019-01-22 13:36, Parkinbot wrote:

Carsten,

being able to extrude a 2D object (with holes) along a fancy path in
extension of linear_extrude would be a nice to have (without having to
install angelscript :-) ),

You don't need angelscript to do it. The xcsg application knows nothing
about angelscript, it only relates to the specification of the wiki at
https://github.com/arnholm/xcsg/wiki . In theory, OpenSCAD could be an
alternative front end.

but the discussed approach is even more
ambitious. Just read the thread from start.
The multi hole sweep will allow each polygon to morph along the path,
like
shown in the following example code that "extrudes" a CW screw with a
CCW
hole:
http://forum.openscad.org/file/t887/CWCCW.png

Ok, that was the part I was missing then, thanks. I agree that is more
ambitious.

Talking about morphing, I have tried that (with holes also)
https://github.com/arnholm/xcsg/wiki/transform_extrude , but not in
combination with a general sweep path.

Carsten Arnholm

On 2019-01-22 13:36, Parkinbot wrote: > Carsten, > > being able to extrude a 2D object (with holes) along a fancy path in > extension of linear_extrude would be a nice to have (without having to > install angelscript :-) ), You don't need angelscript to do it. The xcsg application knows nothing about angelscript, it only relates to the specification of the wiki at https://github.com/arnholm/xcsg/wiki . In theory, OpenSCAD could be an alternative front end. > but the discussed approach is even more > ambitious. Just read the thread from start. > The multi hole sweep will allow each polygon to morph along the path, > like > shown in the following example code that "extrudes" a CW screw with a > CCW > hole: > <http://forum.openscad.org/file/t887/CWCCW.png> Ok, that was the part I was missing then, thanks. I agree that is more ambitious. Talking about morphing, I have tried that (with holes also) https://github.com/arnholm/xcsg/wiki/transform_extrude , but not in combination with a general sweep path. Carsten Arnholm
P
Parkinbot
Tue, Jan 22, 2019 2:41 PM

cacb wrote

You don't need angelscript to do it. The xcsg application knows nothing
about angelscript, it only relates to the specification of the wiki at
https://github.com/arnholm/xcsg/wiki . In theory, OpenSCAD could be an
alternative front end.

thanks for the hint. I always wanted to find out how to use MATLAB as a
frontend. Hope I'll soon find time to dig deeper into this interesting
approach.

cacb wrote

Talking about morphing,

OK, this is a trivial linear interpolation and more or less a one-liner, if
you have arithmetics operating over point lists.

--
Sent from: http://forum.openscad.org/

cacb wrote > You don't need angelscript to do it. The xcsg application knows nothing > about angelscript, it only relates to the specification of the wiki at > https://github.com/arnholm/xcsg/wiki . In theory, OpenSCAD could be an > alternative front end. thanks for the hint. I always wanted to find out how to use MATLAB as a frontend. Hope I'll soon find time to dig deeper into this interesting approach. cacb wrote > Talking about morphing, OK, this is a trivial linear interpolation and more or less a one-liner, if you have arithmetics operating over point lists. -- Sent from: http://forum.openscad.org/
RP
Ronaldo Persiano
Sun, Feb 24, 2019 1:56 PM

After a big good struggle, I have finally devised a way to do a partition
of a polygon with holes in parts which are simple polygons. It does not
find the best partition in the number parts but the partition is limited to
m+1 polygons where m is the number of holes. The OpenSCAD codes of the
method, some tests cases of it and of the sweep of polygon with holes may
be found in my github repository (
https://github.com/RonaldoCMP/Polygon-stuffs). Here I will present and
discuss some cases.

The following image shows the best and worst cases of the method.

[image: polyHolePartition_TheBestAndWorst.PNG]

As the method is biased from left to right and right to left, it is
impossible for it to find a bipartition when the holes are distributed
verticaly. The number of parts in the worst case is m+1.

The worst case for any method (the problem worst case) may be seen bellow.

[image: polyHolePartition_TheWorstProblem.PNG]

This example is based on a case devised by Parkinbot and shows that for
some cases there is no smaller partition than one with m+1 parts.

To evaluate the time spent by the method I run the next case with many
sizes of the matrix of holes and square refinements.

[image: SquareArranje.PNG]

In this example I could change the size of the hole matrix and the number
of vertices in all square edges. In my machine, without square refinements,
the method spent negligible time to get a partition of 49 holes (4*50
vertices), 3s for 100 holes and 13s for 200 holes. With 25 holes and square
refinements, it spent 3s with 1600 vertices (16 per edge) and 9s with 3200
vertices. So, it is very efficient for practical applications.

Now, a real application case: sweeping a polygon with holes with just one
polyhedron call. The shape to be swept is the following, already processed
by the method:

[image: SweepPolygon.PNG]

Sweeping this polygon along a spiral curve with proper code led to:

[image: sweep_polyHoles_1.PNG]

This image is a render of the sweep with a cube subtracted from it to show
it is CGAL palatable. The model was built by "lazy unioning" 6 pieces which
are not manifolds: the two caps, the outer sweep without caps and the 3
hole sweeps without caps. Each of those parts is output by a code that
generates a polyhedron data format [points, faces]. The lazy union module
just "stitches" the incoming polyhedron data together. I have updated my
sweep library in github including a module lazyUnion(), the module that
produced the image.

To get an idea of how that model was produced I show bellow an excerpt of
its main code:

// the face with holes
outer = circ(r=50,n=24); // the outer border
mH    = cxydistr(25, 4, 3, revert(circ(12,24))); // hole borders
// build the polygon for the face with holes
holedFacePDat = polyHolePartition(outer, mH, true);
// main path
path = spiral(200,80,270,24);
// the path transforms
tpath = construct_transform_path(path);
// sweep the outer face and the holes without caps
souter = sweep_polyhedron(outer, tpath, caps=false);
shole0 = sweep_polyhedron(mH[0], tpath, caps=false);
shole1 = sweep_polyhedron(mH[1], tpath, caps=false);
shole2 = sweep_polyhedron(mH[2], tpath, caps=false);
// transform holedFacePDat to put the holed caps in proper place
lpath = len(tpath);
begCap  = tranfPdata(tpath[0], holedFacePDat) ;
endCap  = tranfPdata(tpath[lpath-1], holedFacePDat, inv=true) ;
// join evething in one polyhedron
difference() {
lazyUnion([souter,begCap,endCap, shole0, shole1, shole2]);
translate([-160,50,0]) cube([60,60,150]);
}

Note that polyHolePartition is able to output the partition in one of two
formats depending on its third argument value: a simple list of the
partition polygons (the default) or that partition in polyhedron data
format, that is a list of vertices followed by a list of faces.

Finally, the image of that sweep with edges on reveals an irony.
[image: SweepPolygonEdges.PNG]
After all the work to get a reasonable partition of the polygon with holes,
the alternate construction of OpenSCAD triangulates the sweep shape because
it is not planar after have been geometric transformed to its place!

Em ter, 22 de jan de 2019 às 14:43, Parkinbot rudolf@digitaldocument.de
escreveu:

cacb wrote

You don't need angelscript to do it. The xcsg application knows nothing
about angelscript, it only relates to the specification of the wiki at
https://github.com/arnholm/xcsg/wiki . In theory, OpenSCAD could be an
alternative front end.

thanks for the hint. I always wanted to find out how to use MATLAB as a
frontend. Hope I'll soon find time to dig deeper into this interesting
approach.

cacb wrote

Talking about morphing,

OK, this is a trivial linear interpolation and more or less a one-liner, if
you have arithmetics operating over point lists.

--
Sent from: http://forum.openscad.org/


OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

After a big good struggle, I have finally devised a way to do a partition of a polygon with holes in parts which are simple polygons. It does not find the best partition in the number parts but the partition is limited to m+1 polygons where m is the number of holes. The OpenSCAD codes of the method, some tests cases of it and of the sweep of polygon with holes may be found in my github repository ( https://github.com/RonaldoCMP/Polygon-stuffs). Here I will present and discuss some cases. The following image shows the best and worst cases of the method. [image: polyHolePartition_TheBestAndWorst.PNG] As the method is biased from left to right and right to left, it is impossible for it to find a bipartition when the holes are distributed verticaly. The number of parts in the worst case is m+1. The worst case for any method (the problem worst case) may be seen bellow. [image: polyHolePartition_TheWorstProblem.PNG] This example is based on a case devised by Parkinbot and shows that for some cases there is no smaller partition than one with m+1 parts. To evaluate the time spent by the method I run the next case with many sizes of the matrix of holes and square refinements. [image: SquareArranje.PNG] In this example I could change the size of the hole matrix and the number of vertices in all square edges. In my machine, without square refinements, the method spent negligible time to get a partition of 49 holes (4*50 vertices), 3s for 100 holes and 13s for 200 holes. With 25 holes and square refinements, it spent 3s with 1600 vertices (16 per edge) and 9s with 3200 vertices. So, it is very efficient for practical applications. Now, a real application case: sweeping a polygon with holes with just one polyhedron call. The shape to be swept is the following, already processed by the method: [image: SweepPolygon.PNG] Sweeping this polygon along a spiral curve with proper code led to: [image: sweep_polyHoles_1.PNG] This image is a render of the sweep with a cube subtracted from it to show it is CGAL palatable. The model was built by "lazy unioning" 6 pieces which are not manifolds: the two caps, the outer sweep without caps and the 3 hole sweeps without caps. Each of those parts is output by a code that generates a polyhedron data format [points, faces]. The lazy union module just "stitches" the incoming polyhedron data together. I have updated my sweep library in github including a module lazyUnion(), the module that produced the image. To get an idea of how that model was produced I show bellow an excerpt of its main code: // the face with holes outer = circ(r=50,n=24); // the outer border mH = cxydistr(25, 4, 3, revert(circ(12,24))); // hole borders // build the polygon for the face with holes holedFacePDat = polyHolePartition(outer, mH, true); // main path path = spiral(200,80,270,24); // the path transforms tpath = construct_transform_path(path); // sweep the outer face and the holes without caps souter = sweep_polyhedron(outer, tpath, caps=false); shole0 = sweep_polyhedron(mH[0], tpath, caps=false); shole1 = sweep_polyhedron(mH[1], tpath, caps=false); shole2 = sweep_polyhedron(mH[2], tpath, caps=false); // transform holedFacePDat to put the holed caps in proper place lpath = len(tpath); begCap = tranfPdata(tpath[0], holedFacePDat) ; endCap = tranfPdata(tpath[lpath-1], holedFacePDat, inv=true) ; // join evething in one polyhedron difference() { lazyUnion([souter,begCap,endCap, shole0, shole1, shole2]); translate([-160,50,0]) cube([60,60,150]); } Note that polyHolePartition is able to output the partition in one of two formats depending on its third argument value: a simple list of the partition polygons (the default) or that partition in polyhedron data format, that is a list of vertices followed by a list of faces. Finally, the image of that sweep with edges on reveals an irony. [image: SweepPolygonEdges.PNG] After all the work to get a reasonable partition of the polygon with holes, the alternate construction of OpenSCAD triangulates the sweep shape because it is not planar after have been geometric transformed to its place! Em ter, 22 de jan de 2019 às 14:43, Parkinbot <rudolf@digitaldocument.de> escreveu: > cacb wrote > > You don't need angelscript to do it. The xcsg application knows nothing > > about angelscript, it only relates to the specification of the wiki at > > https://github.com/arnholm/xcsg/wiki . In theory, OpenSCAD could be an > > alternative front end. > > thanks for the hint. I always wanted to find out how to use MATLAB as a > frontend. Hope I'll soon find time to dig deeper into this interesting > approach. > > > cacb wrote > > Talking about morphing, > > OK, this is a trivial linear interpolation and more or less a one-liner, if > you have arithmetics operating over point lists. > > > > -- > Sent from: http://forum.openscad.org/ > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >
P
Parkinbot
Sun, Feb 24, 2019 10:57 PM

Ronaldo,

congrats, it looks like you had a hard time and did a great piece of work.
Without having been able to study and accompany your solution path in
greater detail (I'm currently fully booked and completely out of time) I
think it can work the way you describe it, and the implementation of such an
algorithm in OpenSCAD is a piece of art of its own.

However, I still have the vague hope one could get along with a simple
earcut and a keyhole representation running from the outer polygon over each
of the holes and back to the outer polygon - without dissecting any hole and
WITHOUT even partitioning the polygon once. Your remark

Ronaldo wrote

The polyHoles() code implements the David Eberly method of bridging a
polygon with (any number of) holes in order to apply his earcut
triangulation method  to the resulting (almost) simple polygon. The
polygon polyHoles() returns has no holes but is not really a simple
polygon: some edges of it are traveled twice as you traverse its full
cycle.

has raised this hope, a more or less vague gut feeling. As I understand the
keyhole representation this algorithm generates, it is a means to construct
a fake polygon without a hole from a polygon with holes. As you already
suspected "changing some constraints in the earcut method" might lead to a
much less demanding solution.

--
Sent from: http://forum.openscad.org/

Ronaldo, congrats, it looks like you had a hard time and did a great piece of work. Without having been able to study and accompany your solution path in greater detail (I'm currently fully booked and completely out of time) I think it can work the way you describe it, and the implementation of such an algorithm in OpenSCAD is a piece of art of its own. However, I still have the vague hope one could get along with a simple earcut and a keyhole representation running from the outer polygon over each of the holes and back to the outer polygon - without dissecting any hole and WITHOUT even partitioning the polygon once. Your remark Ronaldo wrote > The polyHoles() code implements the David Eberly method of bridging a > polygon with (any number of) holes in order to apply his earcut > triangulation method to the resulting (almost) simple polygon. The > polygon polyHoles() returns has no holes but is not really a simple > polygon: some edges of it are traveled twice as you traverse its full > cycle. has raised this hope, a more or less vague gut feeling. As I understand the keyhole representation this algorithm generates, it is a means to construct a fake polygon without a hole from a polygon with holes. As you already suspected "changing some constraints in the earcut method" might lead to a much less demanding solution. -- Sent from: http://forum.openscad.org/
RP
Ronaldo Persiano
Tue, Feb 26, 2019 12:47 PM

Parkinbot wrote:

However, I still have the vague hope one could get along with a simple
earcut and a keyhole representation running from the outer polygon over
each
of the holes and back to the outer polygon - without dissecting any hole
and
WITHOUT even partitioning the polygon once. Your remark

Well, that was the goal of David Eberly's paper. It describes an algorithm
to transform a polygon with holes in a fake simple polygon without holes (I
liked this name) . I have implemented a version of this algorithm in my
polyHoles.scad code which is now uploaded in my github repository in its
last version. The fake simple polygon (FSP) it generates has some edges
which are traveled twice when the all the border of the FSP is traveled.
So, it is not a simple polygon. However, although Eberly describes a
version of the ear-cut method for simple polygons at the paper beginning,
he does not  discuss the necessary changes in the method to deal with FSPs.
The conventional ear-cut method does not works directly with FSP. Analysing
my implementation of the ear-cut method, I saw that the check for an ear
should be relaxed to allow other vertices on the ear border. And it seems
to work for FSP with that relaxed conditions.

I have made a comparison between the relaxed ear-cut method and the polygon
partition one. An image of the one result is bellow.

[image: polyComparison.PNG]

We have here a polygon with 4 holes with 4 additional vertices inserted in
every original edge. From left to right, we have the partition of the
polygon made by polyHolePartition, the ear-cut triangulation of the FSP,
and the FSP itself. The partition has 4 parts which are simple polygon, the
triangulation has 106 triangles and the FSP just one polygon. All solutions
have 108 vertices. So the number of parts involved, although reasonable in
the partition case, is very large with the triangulation solution. Besides,
many triangles are very thin, almost degenerate, like the ones just bellow
the two holes at southwest. This may be a cause of troubles in the render
of sweeps.

A run time comparison is even more strikingly against triangulation.
Although the implementation of the ear-cut method is much simpler than the
implementation of the polyHolePartition, the triangulation method is much
more inefficient and spent a lot more time than the partition method when
the number of vertices grows.

To tell you the truth, I don't like the solution of the partition method
(and even less the triangilation). I would prefer far more the FSP
generated by polyHoles. The only reason I developed the implementation of
the partition method is that FSP faces are not acceptable by polyhedrons in
render, although it is acceptable by polygon() and its linear_extrude().
So, my hope is that some day OpenSCAD could deal with polyhedron faces with
the same generality it deals in polygon(). Then, polyHolePartition and
triangulation of faces will be history.

The irony I mentioned in the end of my last message is that anything we do
a partition of a polygon with holes in simple polygons to turn it palatable
to CGAL, the system will discard it and make its own triangulation of the
face.

Parkinbot wrote: > However, I still have the vague hope one could get along with a simple > earcut and a keyhole representation running from the outer polygon over > each > of the holes and back to the outer polygon - without dissecting any hole > and > WITHOUT even partitioning the polygon once. Your remark > Well, that was the goal of David Eberly's paper. It describes an algorithm to transform a polygon with holes in a fake simple polygon without holes (I liked this name) . I have implemented a version of this algorithm in my polyHoles.scad code which is now uploaded in my github repository in its last version. The fake simple polygon (FSP) it generates has some edges which are traveled twice when the all the border of the FSP is traveled. So, it is not a simple polygon. However, although Eberly describes a version of the ear-cut method for simple polygons at the paper beginning, he does not discuss the necessary changes in the method to deal with FSPs. The conventional ear-cut method does not works directly with FSP. Analysing my implementation of the ear-cut method, I saw that the check for an ear should be relaxed to allow other vertices on the ear border. And it seems to work for FSP with that relaxed conditions. I have made a comparison between the relaxed ear-cut method and the polygon partition one. An image of the one result is bellow. [image: polyComparison.PNG] We have here a polygon with 4 holes with 4 additional vertices inserted in every original edge. From left to right, we have the partition of the polygon made by polyHolePartition, the ear-cut triangulation of the FSP, and the FSP itself. The partition has 4 parts which are simple polygon, the triangulation has 106 triangles and the FSP just one polygon. All solutions have 108 vertices. So the number of parts involved, although reasonable in the partition case, is very large with the triangulation solution. Besides, many triangles are very thin, almost degenerate, like the ones just bellow the two holes at southwest. This may be a cause of troubles in the render of sweeps. A run time comparison is even more strikingly against triangulation. Although the implementation of the ear-cut method is much simpler than the implementation of the polyHolePartition, the triangulation method is much more inefficient and spent a lot more time than the partition method when the number of vertices grows. To tell you the truth, I don't like the solution of the partition method (and even less the triangilation). I would prefer far more the FSP generated by polyHoles. The only reason I developed the implementation of the partition method is that FSP faces are not acceptable by polyhedrons in render, although it is acceptable by polygon() and its linear_extrude(). So, my hope is that some day OpenSCAD could deal with polyhedron faces with the same generality it deals in polygon(). Then, polyHolePartition and triangulation of faces will be history. The irony I mentioned in the end of my last message is that anything we do a partition of a polygon with holes in simple polygons to turn it palatable to CGAL, the system will discard it and make its own triangulation of the face.
P
Parkinbot
Tue, Feb 26, 2019 3:00 PM

Hmm, I would expect your example to have a key hole representation similar to
this image:
http://forum.openscad.org/file/t887/FSP.png
So no additional vertices are introduced. When the earcut travels now along
the "outline" of the FSP, it will have to ignore the vertices of an edge
when it analyzes a triangle containing its fake counterpart - or (just a
thought) it might relax a ">=" condition into a ">=" condition (or vice
versa) and thus allow for simple polygons with shared vertices.

--
Sent from: http://forum.openscad.org/

Hmm, I would expect your example to have a key hole representation similar to this image: <http://forum.openscad.org/file/t887/FSP.png> So no additional vertices are introduced. When the earcut travels now along the "outline" of the FSP, it will have to ignore the vertices of an edge when it analyzes a triangle containing its fake counterpart - or (just a thought) it might relax a ">=" condition into a ">=" condition (or vice versa) and thus allow for simple polygons with shared vertices. -- Sent from: http://forum.openscad.org/