3D SLICER STEP 3-- The 3-D preview, and exporting the .stl printer file.

See the attached image as a guide.

From the original 'Welcome to Slicer' menu at the top, choose 'Segment Editor'
instead. This is where the 3-D preview is generated, and where the recreated
voxel model is exported as an .stl triangle-mesh file for 3-D printing.

A) In the 'Source volume' box, the name of your first chosen slice image will
automatically appear.

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.

C) Next to that line on the immediate left is an icon (one of many); this
particular icon looks like two horizontal bars or an = sign. It is called
'threshold', but you will need to hover your mouse over it to bring up the name.
Click on that (or you can use your keyboard's space bar to activate it.)

D) The three orthographic view-panes will start flashing green-- just the
'active' models parts, not the black background. A new data box will also
appear, with a 'threshold' slider, but that does not need adjusting because the
voxel-creation 'threshold' of our white-on-black image slices has been
automatically set. (This slider has an interesting use when CUTAWAY_TEXTURES has
been invoked in the original slicing code-- where the resulting gray-level
pixels can be incorporated as voxels or eliminated.  But that will be described
later.)

E) Press the 'Apply' button in the lower data field. This essentially finalizes
the model, and the green flashing stops. (Be careful not to hit the space bar on
your keyboard after this step; it re-activates the 'threshold' icon...the green
blinking. To escape this, hit the space bar again.)

Now comes the 3-D view generation:
F) Press the 'Show 3D' button, and give the app time to generate the model. Once
it appears, right-click on that view-pane to bring up a menu and choose 'Center
view'. Now you can use your mouse to interactively rotate, zoom, etc.  (Note
that this somewhat crude 3-D preview is not the higher-quality that will
eventually be printed.) At the top of the 3-D view are some icons; experiment
with those to see some interesting features.

At this point, the model's voxels have been automatically 'smoothed' by a
default amount of '0.5', but that can be changed:

G) To the immediate right of the 'Show 3D' button is a downward-pointing arrow.
Click on it to bring up the little 'smoothing' menu. The 'smoothing factor'
slider there can be adjusted between 0.0 and 1.0, and the 3-D view will update--
quickly or not-so-quickly, depending on the object.  You will need to experiment
to choose which value is best for a particular model. My personal preference
when using *hi-rez* original slice images-- i.e. lots of created voxels-- is
between 0.5 and 1.0; even sharp edges are retained.  [BTW: This smooths
individual voxels-- and thus the final .stl triangles, but by simply moving
their vertices; no finer-scale tessellated triangles are created.) Ideally,
sharp-edged objects should have zero smoothing, while curved surfaces should
have 0.5 to 1.0. Unfortunately, that's not possible, so a compromise is
required...but high resolution slice images (and more of them) makes this less
of a problem.]

The model is now ready to be exported as an .stl file:
H1) Of the three arrows to the right of the 'Show 3D' button, click on the
right-most arrow. Choose 'Export to files...' there; the export dialogue box
will appear. You will need to choose a suitable folder location for your file,
using the 'Destination folder' box; search by clicking in that box (not with the
green arrow.) Once chosen, 3D SLICER will remember that location in the future.

H2) Choose .stl as the 'File format', then press the 'Export' button.
                      ***** FINISHED! *****

This is a binary file, not a text file. There is no choice of which, but it can
be easily converted in another app like Meshmixer--should you want to. (3D
SLICER can also export an .obj file,  if  you have a need to edit the model in
another app.)

-------------------
Before hitting the 'Show 3D' button, the initially empty 3-D view shows a 'cubic
volume' in red outlines...probably a default bounding-box. When the 3-D view is
activated, the object appears in the upper right  quadrant of that volume-- in
the x/y/z  'positive space' quadrant-- instead of at the center. (Imagine
POV-ray's x/y/z origin planes going through the center of that cubic space.)
Apparently, a medical CT scan will be automatically centered in that cube(?)
because it has both 'positive and negative' values in its data-- probably based
on the central horizontal axis of the particular CT machine. Whereas, the
POV-ray image slices have pixels that are all 'positive values' so to speak, no
'negative pixels'. Thus the model initially shows up in the upper-right 'fully
positive' space.  By centering the view in step F) above, the model is
re-centered within the red outlines (and in a more tight-fitting box).

There is a neat trick in this 'Segment Editor', after applying 'Show 3D': Press
and hold cntrl+left mouse button and slide the mouse from right to left in any
of the 3 orthographic views. The 3-D model becomes more or less transparent--
fully solid at the right, fully transparent at the left. You can see all of the
object's  internal surfaces, like an x-ray! (This does not affect the final
export.)

Once you have done these 'Seqment Editor' steps, there is a way to determine how
many actual voxels have been created. 3D SLICER has 'extra' features in another
pull-down menu at the top called  'Modules'.  Use the magnifying glass icon
there to open it, then search for the 'Segment Statistics' module.  Open that,
then open 'Advanced' from the data field,  then hit 'Apply'.  (Afterward, to
close the statistics box that appeared, go back to the top of the app and choose
the 'Four-Up' view again.)

Post a reply to this message

Attachments:
Download '3d slicer step 3-- 3d preview and exporting-- kw 2024.jpg' (705 KB)

Preview of image '3d slicer step 3-- 3d preview and exporting-- kw 2024.jpg'

[importing the .stl file into CURA, and printing the final model]

The attached image shows the final result: the .stl file brought into my
printer's software (Ultimaker CURA) then printed with medium-quality settings
and a standard 0.4mm print nozzle.

As previously mentioned, this demonstration model was 'sliced' at "low to
medium" quality (from the POV-ray returned messages)-- 522 X 269 pixels, 249
slices. That included a number of black slices at the beginning and end of the
animation. Much better results can be obtained with higher rez images and some
adjustments there. BTW: This model in 3D SLICER ended up having 7,076,000 active
voxels. (None are created from black pixels.)

The honeycomb infill I used-- added in CURA-- was only for supporting any flat
horizontal surfaces in the model, and a few areas on the spheres. Surprisingly,
angled surfaces down to 45-deg from vertical can be printed without supports.

In most cases, the model-as-.stl will be much larger that typical desktop
printers can print-- CURA adds stripes to a model to indicate that it's
oversized-- so it needs to be down-sized in your printing software. This has the
great advantage of reducing the size of the voxel-created triangles--
sharpening-up the model-- and is key to the entire process.

Post a reply to this message

Attachments:
Download 'final printing via cura-- kw 4_2024.jpg' (521 KB)

Preview of image 'final printing via cura-- kw 4_2024.jpg'

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

> This is a step-by-step guide to 3-D-print almost any type of POV-ray object ....

Well, ... Damn.

You HAVE been busy, haven't you?

Excellent work, fellow Walker!

How's that Creality printer treating you?
Maybe you'll have an FGC9 to print soon   :D


- BE

Post a reply to this message

Op 6-4-2024 om 13:24 schreef Kenneth:
> 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.
> 

Wow! This is a serious piece of work, Kenneth! Well done indeed!

-- 
Thomas

Post a reply to this message

Thanks BE and Thomas!

You would not *believe* the number of hours I have spent on this project, with
the explanations and code and screenshots-- re-editing almost daily, adding
stuff, erasing stuff, making corrected screenshots, choosing what to include and
what to leave out as unnecessary, making more 3-D test printings etc etc. I kept
telling a few friends that I could probably write a BOOK about it all. But it
sure has been fun :-) For the last couple of weeks, I've been almost
single-minded about finishing it. Now I'm exhausted, ha.

Over the intervening months since last November, I also made some important
discoveries about how 3D SLICER actually works-- by trial and error. My earlier
tests and printed model examples used a much simpler slicing scheme-- which
resulted in squashed-or-stretched results in that app, that I had to re-scale by
eye. Then a 'eureka' moment FINALLY occurred, and my 'automatic' slicing scheme
was the result.

BE: I thought a lot about your earlier suggestion of using POV-ray's 'object
pattern' as a simpler and standard approach to the slicing-- but 3D SLICER's
method of operation makes that approach difficult.  (The proper scaling of the
object there requires a certain number of image slices, not arbitrary like I
originally thought.) A POV-ray object's bounding-box size turned out to be the
answer to that problem-- and object_patterns don't have those. Of course, an
object_pattern has a 1:1 size correspondence with the object it is *made* from,
so I could have used that to get the bounding-box size. Hmm, at some point I
might re-write my code to try that approach!

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!

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.

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