### Hull over a for is squashing everything

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-((percent2)-1)^2))^1.0.8;
bend = 0; //sqrt(1-((percent2)-1)^2);
// cos(percent
PI2 * 57.2958) * .3 +.7;
// echo(percent,ooze_scale);
translate([0,-percent
100,percent100 + 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.

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

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

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

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

``````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
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

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

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.

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:

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

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.

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.