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

Well, from the image pixels on the 'outer surfaces' of the white-on-black
slices, the pixels at the outer edges of the object. Possibly using eval_pigment
and a tracing loop, to somehow get all of those pixel positions-- and just
those-- as well as on inner holes and enclosures. I have some half-formed
ideas...

Post a reply to this message

"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

On 06.04.2024 16:47, Kenneth wrote:

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

This may be an interesting idea, assuming I can understand that format 
(do I understand it right that you printer requires some STL, and that's 
that STL I'm reading about at 
https://en.wikipedia.org/wiki/STL_(file_format) ?). Sounds like they 
have a text version of it.

The problem I see right now is that we have different number of "outline 
pixels" at every section. Other than that, idea of slicing any object 
into set of planar sections, then reconstructing from this looks brutal 
;-) But the problem is, the number of control points change between 
sections (sometimes they completely disappear), and I don't see a way to 
figure out how to deal with it. But well, it looks like an interesting 
idea to think of in background process.

Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

On 07.04.2024 0:31, Ilya Razmanov wrote:

> The problem I see right now is that we have different number of "outline 
> pixels" at every section.

...on the other hand, if you dissect 3D with planes, who can stop me 
from further dissecting 2D slices thus obtained with scanlines? That may 
be it...

Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

Il 06/04/2024 13:24, Kenneth ha scritto:
> See my earlier introductory post about this topic...
> 
>
https://news.povray.org/povray.binaries.images/thread/%3Cweb.655527ca7165e2419b4924336e066e29%40news.povray.org%3E/
> 
> Here it is, finally-- only 5 months late! Real-life got in the way, but I also
> spent time simplifying the required steps and re-writing the 'object slicing'
> code for POV-ray...then tested everything on an almost-daily basis.
[...]

Wonderful results!

Paolo

Post a reply to this message

Ilya Razmanov <ily### [at] gmailcom> wrote:
>
> This may be an interesting idea, assuming I can understand that format
> (do I understand it right that you printer requires some STL, and that's
> that STL I'm reading about at
> https://en.wikipedia.org/wiki/STL_(file_format) ?). Sounds like they
> have a text version of it.

Yes, the 3-D printer's software requires the final object to be in the .stl file
format-- either as a text file or a binary one. The 3D SLICER app can only
export it as a binary type, but that can be brought into another app like
Meshmixer to change it to a text file. However, the binary version results in a
much smaller file size. The Wikipedia entry is using the text version as an
example there.
>
> The problem I see right now is that we have different number of "outline
> pixels" at every section. Other than that, idea of slicing any object
> into set of planar sections, then reconstructing from this looks brutal
> ;-) But the problem is, the number of control points change between
> sections (sometimes they completely disappear), and I don't see a way to
> figure out how to deal with it.
>

Yes, it is a mighty big problem to try and solve! (3D SLICER's algorithm changes
them into voxels first-- somehow. But even there, the ultimate voxel-to-triangle
conversion can be a bit...strange... when individual 'naked' voxels are
processed that do not have surrounding neighbors.)

> ...on the other hand, if you dissect 3D with planes, who can stop me
> from further dissecting 2D slices thus obtained with scanlines? That may
> be it...

YES, that is the general idea I have as well. I am going to write some quick
'demonstration' scanning/eval_pigment code to see if I can make it work-- on at
least ONE sliced image. I *should* end up with another image that has just a
white-pixel shell, at only the outer surfaces of the white object as well as at
holes and voids.

This is just an interim step while I continue to think...  ;-)

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "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!
>
> [BE:]
> 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.
> [snip]
> 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.
> [snip]

Agreed. Your comments are a masterful analysis of the problems involved...and so
quickly! You amaze me.

I was thinking more along the lines of taking the already-made slice images and
using *those* as the basis for further pixel-to-triangle conversion (somehow),
thereby eliminating the scanning problems inherent in tracing the actual object
with inside/outside tests or whatever. The images have nicely-defined
black-to-white transitions, even for holes, undercuts, and internal voids.
Further processing of those images could(?) get us a nicely-defined *shell* of
white pixels at all the required locations-- for the then-MAJOR task of
conversion to triangles. That's my half-formed (half-baked?!) idea so far.

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

Yep, I'm beginning to see the problems now-- even the most fundamental one of:
What should each image pixel represent as a triangle conversion? One triangle?
Multiple ones? POV-ray's internal height_field-from-image algorithm uses 4
neighboring pixels to create... two triangles. A similar scheme may or may not
be appropriate, I don't know.

There is also the problem of 'handed-ness' for each triangle-- that is, which
triangle should have clockwise or counter-clockwise ordering of the three vertex
points (which determines the single face-normal required for each final.stl
triangle, to determine which direction it should face for printing.)
>
> Now, your mention of heightfields, and my armchair consideration of those,
> gave me an idea.
>
> The concept is this:
>
> 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.
> [snip]
>

We're thinking along the same lines ;-)

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> [In 3D SLICER STEP 3-- The 3-D preview, and exporting the .stl printer file]
>
> B) Press the large '+Add' button. An entry line will appear called
> 'Segment_1'. This will eventually be the default name of your exported file,
> but you can double-click on it here to re-name it as anything you like.
>

I forgot to mention that 3D SLICER automatically appends 'Segmentation' to the
beginning of the exported .stl file name. So it will be saved as either
              Segmentation_Segment_1  (the default)
or
              Segmentation_ ... your chosen file name...

Post a reply to this message

On 08.04.2024 0:24, Kenneth wrote:

> Yes, it is a mighty big problem to try and solve! (3D SLICER's algorithm changes
> them into voxels first-- somehow. But even there, the ultimate voxel-to-triangle
> conversion can be a bit...strange... when individual 'naked' voxels are
> processed that do not have surrounding neighbors.)

I don't see much problems in turning layers of pixels (which you have 
already) into voxels. What as to turning this voxel volume into surface 
mesh - that's where the problem is. I took a quick look at some stuff 
used for this in scientific area - it's definitely not a simple trick I 
was thinking of. Still, I promise to think of a simple trick some more :-)

> least ONE sliced image. I *should* end up with another image that has just a
> white-pixel shell, at only the outer surfaces of the white object as well as at
> holes and voids.

Well, turning BW slice into BW contour is, most likely, not a big 
problem (going to try some ideas when I have more time), but I'm 
thinking of making some external program rather than using POVRay for 
that. With POVRay, I'm not so much experienced with SDL to see the solution.

"But we keep our experiments going, for human health is our primary 
goal" (c)

Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

On 08.04.2024 1:46, Kenneth wrote:

> Yep, I'm beginning to see the problems now-- even the most fundamental one of:
> What should each image pixel represent as a triangle conversion? One triangle?
> Multiple ones? POV-ray's internal height_field-from-image algorithm uses 4
> neighboring pixels to create... two triangles. A similar scheme may or may not
> be appropriate, I don't know.
Hehehe, as I've told once already, in my simple img2mesh program:

https://github.com/Dnyarri/img2mesh

I use 1 pixel to produce 4 triangles ;-) That is, it replaces 1 pixel 
with a pyramid of 4 triangles. No slow and memory-hungry tesselation but 
perfect match of pyramid's corners pretty fast :-)

Besides, I guess resulting structure will be compatible with stl specs. 
I will definitely check this out as soon as I get more spare time for 
programming. If it works, it will mean that at least I know how to write 
stl so I may turn to thinking of main task finally ;-)

Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message