On 7/19/2022 6:09 PM, benjaminhill@gmail.com wrote:

Complete example that we can run, please.

I figured it out!  You can't hull a circle, you have to hull two cylinders.

module right_connector_ooze(
slices = 50
) {
module ooze_step(percent) {
ooze_scale = 1-(sqrt(1-((percent2)-1)^2))^1.0.8;
bend = 0; //sqrt(1-((percent2)-1)^2);
// cos(percentPI2 * 57.2958) * .3 +.7;
// echo(percent,ooze_scale);
translate([0,-percent100,percent100 + bend * 10])
rotate([percent90,0,0])
scale([ooze_scale,ooze_scale,1])
children(0);
}

module all_segments() {
    for (i=[1:slices]) {
        percent0 = (i-1)/slices;
        percent1 = i/slices;
        hull() {
            color("green")
            ooze_step(percent0) children(0);
            color("blue")
            ooze_step(percent1) children(0);
        }
    }
}

all_segments() children(0);

}

right_connector_ooze(200) {
cylinder( d = 60, h=0.00001, $fn = 40);
}

On Tue, Jul 19, 2022 at 7:24 PM Jordan Brown openscad@jordan.maileater.net
wrote:

Branching of thread on the "usual 2D/2D confusion

On Wed, 20 Jul 2022 at 05:06, Jordan Brown openscad@jordan.maileater.net
wrote:

I noticed many other CAD programs also start with a 2D sketch or sketches
that are combined/transformed into the 3D object.Probably no coincidence -
or perhaps because we actually think easier in 2D.

Anyhow, for OpenSCAD my suggestion would be to render 2D objects in a
different way (colour? shading?) in the F5/preview than 3D objects. It
seems that  2D objects in preview are 1 mm (sorry, 1 "unit" there is no
scale), so another way is to dynamically change the thickness so they
appear infinitely thin at any zoom level?

Lastly, flag any operation with a 3 element vector (translate,scale etc) on
a 2D object with a warning (rotate with only Z a bothersome exception) Damn

• thinking about it, We need to ensure hull() only has 2D children, any
  combination with a 3D object .... OK, not trivial.

Msquare

On 7/20/2022 9:05 AM, Michael Möller wrote:

Non-closed polyhedra are infinitely thin.  A 2D object could be a
special case (coplanar) of a non-closed polyhedron.

(But note:  if we ever add a 1-D subsystem, to allow for lines, they
couldn't be infinitely thin because they'd be invisible from all
angles.  They could be hairlines, constant thickness independent of zoom.)

Scale isn't really a problem, since a zero-height object is still
zero-height no matter how much you scale up its Z.

Hull already warns about mixing 2D and 3D children:

WARNING: Mixing 2D and 3D objects is not supported in file , line 3

Perversely, hull of 2D and 3D objects, or of 2D objects moved off the XY
plane, would be useful; it would allow exactly what the OP was trying
to achieve, forming a 3D object by hulling together pairs from a
sequence of 2D objects in space.  (3D hull does appear to work on
non-closed polyhedra.)

More generally, I think we've occasionally seen requests to hull point
clouds, which are collections of zero-D objects translated in 3-space.

I often do this by making 2D objects with a 3rd dimension that is 0.01. 
They are actually 3D objects, but with trivial 3rd dimension

On 7/20/2022 1:40 PM, Jordan Brown wrote:

You can hull a point cloud by making a bogus polyhedron that contains
all the points with the points grouped into arbitrary 3-point "faces".
More direct support for this would be nice.

On Wed, Jul 20, 2022 at 1:41 PM Jordan Brown
openscad@jordan.maileater.net wrote:

Could this not be used for reconstructing a shape from gcode output of a
slicer, assuming the original shape was not available.

On Thu, Jul 21, 2022, 01:40 Jordan Brown openscad@jordan.maileater.net
wrote:

On 7/21/2022 1:35 AM, Tim Hawkins wrote:

In a sense, sure, but only in a sense.

Indeed, a G-code file for 3D printing describes a collection of
cylindrical paths.  (Probably more oval than cylindrical, if you want to
be precise.)

And indeed you could take that path and reconstruct it into a bunch of
polyhedra.

But would it be useful?

I happen to have an STL handy of a 1cm x 1cm x 0.5cm cuboid.  My slicer
turns that into 18,000 G-code instructions.  Most of those are G1s -
straightforward moves, generating a cylindrical segment.  Even if we
model the plastic path as a sequence of cuboids, without any rounding,
that's 4x 18,000 = 72,000 points.  For a tiny cuboid.  (My slicer is set
to use gyroid fill, which generates a lot of instructions because the
infill is curvy.  A simpler fill yields 2100 G1s.  Still a lot... and
you don't get to control how the other person configured their slicer.)

A larger sample, a filial for a curtain rod, yields 176,000 instructions
using a simple infill and 551,000 instructions with a gyroid infill.

Can OpenSCAD realistically work with an object that complex?  I don't
happen to know, but I don't think my models are anywhere near that
complex.  How long would hundreds of thousands of hull operations take?

And the filial demonstrates another problem:  a G-code file may have
support structures in it, and there's no way for a processing program to
know that those pieces of filament should be discarded while others are
retained.

Of course, the result is nothing like the original model would be.  It
will include - because it must, because without sophisticated geometry
analysis it can't tell the difference - all of the infill as part of
the model.  Even if it survives OpenSCAD, will it re-slice reasonably?

You don't need to use hull anyway; if you have the eight points that
represent the bounds of a particular move, you can just directly
generate a polyhedron.

Obligatory special-case note:  if the object is convex, you could hull
the whole thing and get back to reasonable geometry.  But how many
interesting models are convex?

You might be better off printing the object and then 3D scanning it.  At
least then your model would only include the exterior, and probably some
of the filament detail would get simplified.

You can't turn sausage back into steak.