Actually whether it is "doable" to have a form of linear extrude which can
join sections with mismatched point count is debatable.  As I found in my
work on skin() for BOSL2, there is no one right way to join sections.
Sometimes you need one approach, and sometimes another.  Sometimes
multiple approaches give different, reasonable results and the user ought
to be given a choice.  Most likely major issues will arise with strongly
concave inputs---such an algorithm cannot be robust to all inputs.  For
example, what happens in joining a ring (with an internal hole) to a
square?  Is it acceptable for an OpenSCAD built-in module to fail on some
inputs?  Even if we deem bad output acceptable on some inputs, you end up
with a very complicated interface.  Again, take a look at the interface to
skin() in BOSL2.  It is not simple.  The same problem afflicts the idea of
path_sweep(), a concept people have been talking about for years, but which
has enormous hidden complexity that, it seems, has prevented it from being
implemented as a built-in module.

You talk of moving in that direction.  What kind of movement could be done
that avoids all of these complications?  Perhaps if you can come up with a
well-formed idea someone may some day implement it.

On Sat, Jan 21, 2023 at 9:30 AM Rogier Wolff R.E.Wolff@bitwizard.nl wrote:

If there are 2 sections who's points needs to be matched are say a and b.

Consider rays emanating from the center of section a outwards at 360
degrees.

If each ray intersects the sections a and b at exactly 1 point it should be
doable, otherwise I don't think it will be possible.

On Sat, 21 Jan, 2023, 8:38 pm Adrian Mariano, avm4@cornell.edu wrote:

I think your condition is sufficient by not necessary.  If section A and
section B don't overlap, for example, but they are otherwise well behaved,
it is likely that they can still be aligned.  There may be non-convex cases
where some algorithm exists that produces a reasonable alignment, for
example by resampling both sections to have a fine sampling with the same
number of points, sampling uniformly in length---assuming a suitable
starting point is identified somehow.

The other thing is that your condition doesn't actually provide an
alignment algorithm that always produces a good result.  For example, in
connecting a pentagon to a square the result of such an algorithm will be
ugly.  You need instead to match up the vertices somehow, and collapse two
pentagon vertices onto one square vertex.

On Sat, Jan 21, 2023 at 1:02 PM Sanjeev Prabhakar sprabhakar2006@gmail.com
wrote:

This is for complex use cases.

For pentagon to square can be a nearest point mapping, which is fairly easy
to achieve.

Regards

On Sat, 21 Jan, 2023, 11:55 pm Adrian Mariano, avm4@cornell.edu wrote:

I mean of both the sections are convex it should be simpler

If either or both the sections are concave it would be a little or more
complex based on the shape

On Sun, 22 Jan, 2023, 12:00 am Sanjeev Prabhakar, sprabhakar2006@gmail.com
wrote:

On 1/21/2023 10:24 AM, Adrian Mariano wrote:

I was curious what a "match up by angle" algorithm would produce, so I
wrote something kind of similar.  It samples both polygons the same
number of times, linearly along the perimeter, and connects them.  The
result is ... interesting.  I don't know that it's right, but I also
don't know that it's wrong.  Most disturbing is that one side ends up
flat while the others end up curved.

sides_a = 4;
sides_b = 5;
n = 80;
ir = 10;
h = 20;

samples_per_side_a = n / sides_a;
samples_per_side_b = n / sides_b;

// Generate points for one side of a polygon, as a vertical line in +X,
// centered around Y=0.
function points(ir, side, n) = [
for (i=[0:n-1]) [ ir, i*side/n - side/2 ]
];

// Given a 2D point and an angle, rotate the point.
function rot(p, a) = p * [ [ cos(a), sin(a) ], [-sin(a), cos(a)] ];

// Calculate the points for each polygon by generating N sides and rotating them.
pts_a = [ for (i=[0:sides_a-1]) let(a=i360/sides_a) each [ for (p=points(ir, 2tan(360/sides_a/2)*ir, samples_per_side_a)) rot(p, a) ] ];

pts_b = [ for (i=[0:sides_b-1]) let(a=i360/sides_b) each [ for (p=points(ir, 2tan(360/sides_b/2)*ir, samples_per_side_b)) rot(p, a) ] ];

// All of the points of the polyhedron.
points = [
for (p = pts_a) [ p.x, p.y, 0 ],
for (p = pts_b) [ p.x, p.y, h ]
];

// All of the faces - bottom, top, sides.
faces = [
[ for (i = [0:n-1]) i ],
[ for (i = [n-1:-1:0]) n+i ],
for (i = [0:n-1]) [ i, i+n, (i+1)%n ],
for (i = [0:n-1]) [ (i+1)%n, i+n, (i+1)%n + n ]
];

polyhedron(points=points, faces=faces);

On 2023-01-21 10:38 a.m., Sanjeev Prabhakar wrote:

Indeed. And if I have understood the enhancement being discussed, in the
case of two convex ends you can already achieve the required effect with
current OpenSCAD facilities. That is, if both ends of the extruded shape
are fully convex (continuously convex along the perimeters) then the
required morphing can be achieved using hull of two 'cones', one of
which is inverted. The method requires that both starting 2D shapes must
surround the z axis/x-y origin, but you can use multmatrix afterwards to
skew the 3D shape if you need to have one end outside the z axis.

In the example below, I made the cones from SVG outlines by using
linear_extrude with scale = 0. For an end that is an ordinary polygon, I
would create a cone using the cylinder command with one of the r
parameters set to zero and a suitable $fn value (maybe also rotating it
around z axis to get a nice outline).

Here, red is the inverted cone, green the upright cone, grey is the
hulled object.

Steve

On 1/21/2023 12:24 PM, Steve Lelievre wrote:

I'm missing what the cone-ness brings to the picture, versus just having
each of them infinitesimally thin and then hulling them.

(But note that hull won't help if the figures aren't convex.)

If you use very thin cylinders you get extra edges very close together,
which can cause issues. Cones avoid that as the base is a single edge
rather than two very close together.

On Sat, 21 Jan 2023 at 20:45, Jordan Brown openscad@jordan.maileater.net
wrote:

Jordan,

I like the cones because they only involve the one perimeter at the wide
end so the shape produced is completely 'correct' in geometrical terms.
As well, to me the code required is just as simple as it is for flat end
shapes.

And yes, I agree (and also mentioned) that the hulling option is only
valid for convex end shapes. The good thing about it is that it's here now.

Steve

On 2023-01-21 12:43 p.m., Jordan Brown wrote: