Hi,

Guest

B

benjaminhill@gmail.com

Wed, Jul 20, 2022 1:09 AM

I’ve got a `for (i=[1:slices]) {` that creates the “spine” of a shape.

Then I’ve got a “for each pair of spine, hull it”

```
for (i=[1:slices]) {
// hull() {
percent0 = (i-1)/slices;
percent1 = i/slices;
color("green")
ooze_step(percent0) children(0);
color("blue")
ooze_step(percent1) children(0);
// }
}
But when I wrap the pairs in "hull" (uncommenting), it "squashes" the entire thing into the x/y plane.
```

I’ve got a \`for (i=\[1:slices\]) {\` that creates the “spine” of a shape.
Then I’ve got a “for each pair of spine, hull it”
```
for (i=[1:slices]) {
// hull() {
percent0 = (i-1)/slices;
percent1 = i/slices;
color("green")
ooze_step(percent0) children(0);
color("blue")
ooze_step(percent1) children(0);
// }
}
But when I wrap the pairs in "hull" (uncommenting), it "squashes" the entire thing into the x/y plane.
```

JB

Jordan Brown

Wed, Jul 20, 2022 2:24 AM

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

I’ve got a `for (i=[1:slices]) {`

that creates the “spine” of a shape.

Then I’ve got a “for each pair of spine, hull it”

|for (i=[1:slices]) { // hull() { percent0 = (i-1)/slices; percent1 =

i/slices; color("green") ooze_step(percent0) children(0);

color("blue") ooze_step(percent1) children(0); // } } But when I wrap

the pairs in "hull" (uncommenting), it "squashes" the entire thing

into the x/y plane. |

Complete example that we can run, please.

On 7/19/2022 6:09 PM, benjaminhill@gmail.com wrote:
>
> I’ve got a `for (i=[1:slices]) {` that creates the “spine” of a shape.
>
> Then I’ve got a “for each pair of spine, hull it”
>
> |for (i=[1:slices]) { // hull() { percent0 = (i-1)/slices; percent1 =
> i/slices; color("green") ooze_step(percent0) children(0);
> color("blue") ooze_step(percent1) children(0); // } } But when I wrap
> the pairs in "hull" (uncommenting), it "squashes" the entire thing
> into the x/y plane. |
>
Complete example that we can run, please.

BH

Benjamin Hill

Wed, Jul 20, 2022 2:55 AM

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-((percent*2)-1)^2))^1.0*.8;

bend = 0; //sqrt(1-((percent*2)-1)^2);
// cos(percent*PI

// echo(percent,ooze_scale);

translate([0,-percent

rotate([percent

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:

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

I’ve got a `for (i=[1:slices]) {`

that creates the “spine” of a shape.

Then I’ve got a “for each pair of spine, hull it”

for (i=[1:slices]) {

// hull() {

percent0 = (i-1)/slices;

percent1 = i/slices;

color("green")

ooze_step(percent0) children(0);

color("blue")

ooze_step(percent1) children(0);

// }

}

But when I wrap the pairs in "hull" (uncommenting), it "squashes" the entire thing into the x/y plane.

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-((percent*2)-1)^2))^1.0*.8;
bend = 0; //sqrt(1-((percent*2)-1)^2);
// cos(percent*PI*2 * 57.2958) * .3 +.7;
// echo(percent,ooze_scale);
translate([0,-percent*100,percent*100 + bend * 10])
rotate([percent*90,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:
> On 7/19/2022 6:09 PM, benjaminhill@gmail.com wrote:
>
> I’ve got a `for (i=[1:slices]) {` that creates the “spine” of a shape.
>
> Then I’ve got a “for each pair of spine, hull it”
>
> for (i=[1:slices]) {
> // hull() {
> percent0 = (i-1)/slices;
> percent1 = i/slices;
> color("green")
> ooze_step(percent0) children(0);
> color("blue")
> ooze_step(percent1) children(0);
> // }
> }
>
> But when I wrap the pairs in "hull" (uncommenting), it "squashes" the entire thing into the x/y plane.
>
>
>
> Complete example that we can run, please.
>
>

JB

Jordan Brown

Wed, Jul 20, 2022 3:06 AM

You certainly can hull circles. But what you get is a 2D result.

What you can't do without weird results, and maybe should be an error,

is to move circles (or any other 2D object) off of the XY plane - like

by rotating or translating them.

It looks like 2D hull flattens its children back down onto the XY plane

before doing its thing.

[ Following is for OpenSCAD experts... ]

Really, I kind of think that the behavior of 2D objects is just wrong,

that they should be implemented as non-closed polyhedra so that they are

zero-thickness. That might also let them be used in 3D operations. But

it might also open a can of worms: what happens if you linear_extrude

an object that isn't confined to Z=0? Also, the 2D subsystem has the

advantage of being very fast.

Maybe they should be implemented as a separate class of object, but
*displayed* as non-closed polyhedra.

You certainly can hull circles. But what you get is a 2D result.
What you can't do without weird results, and maybe should be an error,
is to move circles (or any other 2D object) off of the XY plane - like
by rotating or translating them.
It looks like 2D hull flattens its children back down onto the XY plane
before doing its thing.
---
[ Following is for OpenSCAD experts... ]
Really, I kind of think that the behavior of 2D objects is just wrong,
that they should be implemented as non-closed polyhedra so that they are
zero-thickness. That might also let them be used in 3D operations. But
it might also open a can of worms: what happens if you linear_extrude
an object that isn't confined to Z=0? Also, the 2D subsystem has the
advantage of being very fast.
Maybe they should be implemented as a separate class of object, but
*displayed* as non-closed polyhedra.

MM

Michael Möller

Wed, Jul 20, 2022 4:05 PM

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

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

wrote:

[ Following is for OpenSCAD experts... ]

Really, I kind of think that the behavior of 2D objects is just wrong,

that they should be implemented as non-closed polyhedra so that they are

zero-thickness. That might also let them be used in 3D operations. But it

might also open a can of worms: what happens if you linear_extrude an

object that isn't confined to Z=0? Also, the 2D subsystem has the

advantage of being very fast.

Maybe they should be implemented as a separate class of object, but
*displayed* as non-closed polyhedra.

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

Branching of thread on the "usual 2D/2D confusion
On Wed, 20 Jul 2022 at 05:06, Jordan Brown <openscad@jordan.maileater.net>
wrote:
> [ Following is for OpenSCAD experts... ]
>
> Really, I kind of think that the behavior of 2D objects is just wrong,
> that they should be implemented as non-closed polyhedra so that they are
> zero-thickness. That might also let them be used in 3D operations. But it
> might also open a can of worms: what happens if you linear_extrude an
> object that isn't confined to Z=0? Also, the 2D subsystem has the
> advantage of being very fast.
>
> Maybe they should be implemented as a separate class of object, but
> *displayed* as non-closed polyhedra.
>
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

JB

Jordan Brown

Wed, Jul 20, 2022 5:40 PM

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

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?

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.)

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)

Scale isn't really a problem, since a zero-height object is still

zero-height no matter how much you scale up its Z.

We need to ensure hull() only has 2D children, any combination with a

3D object ....

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.

On 7/20/2022 9:05 AM, Michael Möller wrote:
> 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?
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.)
> 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)
Scale isn't really a problem, since a zero-height object is still
zero-height no matter how much you scale up its Z.
> We need to ensure hull() only has 2D children, any combination with a
> 3D object ....
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.

J

jon

Wed, Jul 20, 2022 7:07 PM

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:

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.)

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:
> 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.)

AM

Adrian Mariano

Wed, Jul 20, 2022 10:55 PM

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:

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

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?

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.)

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)

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

We need to ensure hull() only has 2D children, any combination with a 3D object ....

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.

OpenSCAD mailing list

To unsubscribe send an email to discuss-leave@lists.openscad.org

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:
>
> On 7/20/2022 9:05 AM, Michael Möller wrote:
>
> 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?
>
>
> 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.)
>
>
> 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)
>
>
> Scale isn't really a problem, since a zero-height object is still zero-height no matter how much you scale up its Z.
>
> We need to ensure hull() only has 2D children, any combination with a 3D object ....
>
>
> 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.
>
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org

TH

Tim Hawkins

Thu, Jul 21, 2022 8:35 AM

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/20/2022 9:05 AM, Michael Möller wrote:

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?

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.)

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)

Scale isn't really a problem, since a zero-height object is still

zero-height no matter how much you scale up its Z.

We need to ensure hull() only has 2D children, any combination with a 3D

object ....

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

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

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.

OpenSCAD mailing list

To unsubscribe send an email to discuss-leave@lists.openscad.org

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/20/2022 9:05 AM, Michael Möller wrote:
>
> 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?
>
>
> 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.)
>
>
> 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)
>
>
> Scale isn't really a problem, since a zero-height object is still
> zero-height no matter how much you scale up its Z.
>
> We need to ensure hull() only has 2D children, any combination with a 3D
> object ....
>
>
> 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.
>
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>

JB

Jordan Brown

Thu, Jul 21, 2022 1:04 PM

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

Could this not be used for reconstructing a shape from gcode output of

a slicer, assuming the original shape was not available. =

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.

On 7/21/2022 1:35 AM, Tim Hawkins wrote:
> Could this not be used for reconstructing a shape from gcode output of
> a slicer, assuming the original shape was not available. =
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.

Replying to:

Empathy v1.0
2022 ©Harmonylists.com