"Kenneth" <kdw### [at] gmailcom> wrote:

In some ways, I feel that this entire object-slicing-to-3D-SLICER idea is just
an interim step to the POV-ray 3-D printing problem... waiting for some clever
fellow to take the image-slices and instead create a triangle mesh (and .stl
file) *directly* from the image pixels. Like POV-ray does with height_fields
from a single image, but 'stitching together' all the triangles from all the
slices. Then we would have a direct-to-.stl solution!


Well.....  when you convert an image to a heightfield, you already know where
that rectangle is, and you just triangulate it.  Divvy it up into a grid and
then connect the diagonals.  The color dictates the height.

Notice also that you don't have any holes in a heightfield.
Try to make a surface from a photo of Swiss cheese, and you'll begin to
appreciate what the problem is.

In 3D it's even more challenging, because you have internal voids that you need
to find and be aware of.

Now, as for making a mesh, I think that you'd got it twisted around.
The way you're doing it now gives you what you need to 3D print, even if it's
not directly applicable because of the typical workflow.  You need to stack
those layers until you get the full solid object.
Using a mesh or STL, you're actually just storing a shell, which then needs to
get translated to a solid, and then to G-Code to lay out the tool path that
makes those full layers.


So, there are a few challenges that need to be addressed - the first is where is
the object and where is it not?  Trying to do that with trace () is going to
fraught with problems.  Because to map the walls of an internal space, you first
need to know where the internal space IS, in order to start your trace ray at an
appropriate point, but also you still have the problem of you may not be able to
scan a perfectly convex hull, and need to deal with occluding concave
protrusions.

Then once you accumulate all of the scan data, you need to address the issue of
_connectivity_, and I, jr, and other can tell exactly how non-trivial a problem
THAT is.

I personally feel that if we're to have an SDL model-to-mesh library, it's going
to have to use a known method of performing the above tasks accurately and
robustly.
I have also thought about using some sort of Fourier-transform method to convert
the geometry to equations, that could then be used to make the mesh.


Now, your mention of heightfields, and my armchair consideration of those, gave
me an idea.

The concept is this:
(And I'm just laying it out in familiar terms to illustrate the process.   We
could use arrays and inside() tests, and any manner of different practical
implementations to actually achieve the result.)
Let's say you take your slicer method and you now have a slice.  One could scan
the "image" with eval_pigment and see what's white and what's black.  The
position where you switch from one color to the other is obviously an edge.
That would be a triangle vertex.
Once you had all of your slices processed into a point cloud of vertices, you
could scan through it and whatever points were close enough to each other in
different layers, you could connect into triangles.
If there wasn't another layer with a sufficiently close point, you could then
search in the same layer.

Perhaps even if a rudimentary mesh could be made, then something like MeshLab or
other software could clean up the mesh, remove duplicates, close holes, smooth
it, etc.

There are a lot of new and impressive tools like CloudCompare that we might be
able to simply process the raw point cloud with.

And if those techniques work, then we can dig up what algorithms they use to
accomplish those tasks.


- BW

Post a reply to this message