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.

This is a step-by-step guide to 3-D-print almost any type of POV-ray object or
model (bicubic-patch objects being the exception)  -- mathematical primitives
like spheres, cylinders, etc. and CSG constructs of the same; isosurfaces;
'object patterns'; height_fields from images or functions; triangle meshes; even
simple extruded artwork-- most of which have always been a problem to print
because no other app can presently import them from POV-ray and turn them
into .stl files for printing.

This scheme is a two-step process:
1) 'Slicing' the object within POV-ray, as a series of white-on-black image
renders using the animation feature.

2) Bringing these images into a freely-available app called 3D SLICER, which
rebuilds the model as voxels by interpolating between the slice images, and
exports the .stl triangle file for 3-D printing. (A white pixel represents a
voxel; black, no voxel.) 3D SLICER is a professional-grade medical app typically
used by radiologists for viewing and manipulating CT/MRI scans. It is quite a
complex app, with a somewhat unconventional GUI, but only a *few* of its
features are needed, with a few steps. (I knew nothing about this app prior to
experimenting with it.) I run it in Windows 10, but it is also available for Mac
OS and Linux. Downloading this large app takes some time-- the installer is
about 230MB. (The download initially failed for me several times, so don't give
up!)

https://www.slicer.org/

I wrote the attached POV-ray slicing-code scene file specifically for use with
3D SLICER (with apologies for the many comments included.) It uses a
zero-thickness intersection box to create the slices, from the bottom of your
object to the top. The specialized code is necessary because of how 3D SLICER
works  and what it expects to be given as 'data'-- so that the object does not
initially appear distorted there. Once you add your object to the code, an
initial square  'test' render is made; POV-ray's 'messages' pane then returns
important information about the render resolution and number of animation frames
to use for the actual slicing. This is then manually entered on POV-ray's
command line for the animation. I have tested the code extensively in both
v3.7.0 and 3.8 beta 1, with various kinds of objects. There are some slight
differences in how the two versions operate, which are hopefully minimized.

Included is an optional CUTAWAY_TEXTURES_ feature; leave that *off* for now. (It
has an interesting use in 3D SLICER, to be discussed later.)

You will need to re-#declare your model as SLICE_OBJ_  for the code and camera
to work with it.  The model can be any size, and located just about anywhere in
POV-ray's 3-D space; it does not need to be near the <0,0,0> origin. The code
finds it automatically and begins slicing at the bottom surface of its bounding
box (with a little optional tweaking). In many cases, no tweaking is necessary.

I have included a test object in the code, for slicing; my screenshots
describing the 3D SLICER process (to come later) use that as an example. For
that demonstration, I used the "low to medium quality settings" that are
returned in the messages pane-- 522 X 269 resolution, 249 slices.

3D SLICER will work best if the slice images show a pure white object against a
black background; the slicing code produces this automatically. The original
texture(s) of your object can be left as-is; even transparent/translucent
objects are OK. (Unfortunately, any applied 'normal' patterns do not reproduce,
only actual surface displacements. Normals are just a lighting trick within
POV-ray.)

The slice images should be saved as grayscale, because 3D SLICER does not work
well with color data. For that purpose, I have added +fng to the returned
'messages'. In v3.7, this defaults to 16-bit, and cannot be changed, at least on
the command line; in v3.8 beta 1, the default is 8-bit but *can* be changed. 3D
SLICER will work with either mode. (I have purposefully left out the bit-depth
for +fng, as it causes a fatal error in v3.7.) The app can accept PNG or JPEG
files,  but PNG is much better quality and actually results in smaller file
sizes.

There may be a few totally black slices at the beginning and end of your
animation, but *do not* discard them. They are important for the proper scaling
of the object in 3D SLICER.

Each white pixel in an image slice represents a voxel; each slice render can be
thought of as the voxel's  height. By default, 3D SLICER creates each voxel as a
1X1X1mm cube. The size of your object *within POV-ray* has no meaning for the
process; the render resolution and number of slices determines the final model
size-- which can then be scaled down in your printer's software to an
appropriate size for printing. (For example, 500 slices at 800X800 pixels create
a model that could be 800X800mm in the final x/z dimension--which is about
3.5-times larger than my own 220X220mm printer platform; but down-sizing it to
fit also reduces the size of the final .stl triangles, *greatly* improving the
printed quality. The higher the rez and the more image slices, the better; this
is why the entire scheme works well. )

Actually, any simpler slicing scheme would work-- but the object would almost
always appear initially squashed or stretched in 3D SLICER in one dimension, the
height (which could be easily corrected there, but only by eye.) The number of
object slices determines the number of vertical voxels created, and thus the
final height of the recreated model--but the correct number depends on the
slice-image resolution (and the model's x-y-z proportions.)  The attached
slicing code determines this automatically, *and* minimizes wasted black pixels
in the slice renders as well. It might seem logical to think that, for example,
500 slices at 500X500 rez would result in an undistorted model-- but that is not
the case, and every sliced model will be different. 3D SLICER assumes the input
data to be exactly 'cubic by default' (although CT-scans etc are apparently
supplied with their own proper voxel-scaling info.) However, any POV-ray slicing
scheme has no 'scanning-machine information' included, it is just a series of
planar images. This is why the number of object slices should not be chosen
arbitrarily.

Lighting is not used for the slice renders, so they can be run at Quality 0 for
a speed improvement. But should antialiasing be used? I have run lots of tests
both ways, and AA appears to simply add a 'coating' of voxels to the model
rather than smoothing it.  AA essentially produces grayscale pixels in the
renders, whereas no 'half-visible' voxels are created in 3D SLICER, just solid
ones. So I opt for no AA as it is simply faster...and because 3D SLICER has an
optional 'smoothing' feature of its own.

---- USING THE SLICING CODE: ----
1a) First, run a single non-animated *square* render IN COLOR and at full
Quality, with

INITIAL_LINEUP_ = on

500X500 resolution is adequate. Here, the camera sees the *entire* object from
the bottom, and the red area in this image is the found bounding-box size. This
initial temporary render serves two purposes: to check that everything is
working correctly (and to allow some optional adjustments), then to print
important information to the 'messages' pane to use for the animated slicing--
the *actual* render resolution and number of animation frames, etc. Afterwards,
this render can be discarded. (Your textured object may not show up as white in
this render; that's OK.)

1b) The slice renders should be made so that the object 'fills' the slices as
much as possible-- just to eliminate wasted pixels. This is done automatically
for many types of objects, but you can use any of the first four *optional*
adjustments during INITIAL_LINEUP_ to 'tighten up' the object within the red
borders if needed . (You can also use these to crop your model.) The strength of
the adjustments depends on the size of your model in POV-ray. This will also
*change* the returned messages-pane information automatically.

2a) Add the 'messages' information to POV-ray's  command line-- which includes
the setting to turn on the animation-- then, importantly, turn OFF the
INITIAL_LINEUP_.

2b) Prior to running the *complete* animation for slicing, you might want to use
the two optional BB_ADJUST_BOTTOM and BB_ADJUST_TOP features to eliminate any
totally black slices at the beginning and end frames-- to get the slice renders
to start and end on the tiniest model detail instead.  POV-ray's
Subset_Start_Frame and Subset_End_Frame animation features can be used for this.
Example:

If Final_Frame=500...
Subset_End_Frame=1 or 2...or...Subset_Start_Frame=499 or 500. Or more if needed.

Again, any adjustments here will change the messages-pane information, so be
sure to double-check that and make any changes on the command line. *Then* run
the full animation.

(NOTE that these six overall adjustments are not *required*; the slicing scheme
and 3D SLICER will still work fine without them.)

3) The resulting series of images need to be placed in their own folder with
nothing else, and need to be numbered consecutively (which POV-ray does
automatically when animation is used.)

I can post only one attachment at a time here; the additional 3D SLICER steps
and images will follow in sequence.

-------------------
Some additional notes, in no particular order:
Even though the slices are rendered as 'solid' white against black, the final
3-D printed model will not necessarily be solid throughout. Such settings are
specified by your printer's software; it is a simple matter there to print the
object as a hollow shell, or with in-fill etc.

The code uses POV-ray's (invisible) object-bounding-box to place the
camera--*under* the object, looking UP (and very slightly into +z by
necessity)-- so that the resulting model in 3D SLICER appears as we would
typically expect to see it in POV-ray, with the camera in -z looking into +z.
The model  will also be exported in this expected orientation as the .stl file.

There is a practical *limit* to the number of slices that should be made and
their pixel resolution, as concerns 3D SLICER. The reasons are two-fold:  The
final .stl triangles could be far smaller than what is needed to print; and 3D
SLICER's 3-D preview will choke on trying to process too *much* data, to the
point of the app shutting down--based mostly on ram availability, and somewhat
on GPU power. The app's online manual states that it is completely(?) ram-based;
no mention is made of disk-swapping. I have 16GB ram and a built-in GPU, and my
own limit is about 1000 slices at 1000X1000 pixels-- or 1,000,000,000 possible
voxels. Even near that point, the app becomes sluggish and slower to respond--
it is doing a LOT of computations in real-time.

A triangle-mesh object need to be closed and well-behaved, with no missing
triangles. It also needs an inside_vector added, as meshes always do for CSG
operations.

A POV-ray 'object pattern' can also be sliced, but it needs a special set-up:
The pattern needs to be applied to some simple object, so that its bounding box
can be found and measured; and CUTAWAY_TEXTURES needs to be 'on'. The pattern
needs to be white, the object black. Note that INITIAL_LINEUP will not show such
an object pattern, as it is 'encased' in the surrounding object; the pattern
will only appear during the actual slicing. (Another way to slice an object
pattern is to first make an isosurface of it.)

If your height_field object has an unwanted flat base, do *not* use
'water_level' to eliminate it, as this interacts in a strange way with the
slicing code's intersection box. Instead, use BB_ADJUST_BOTTOM  to begin slicing
slightly past that base plane. Note that a HF's optional 'smooth' keyword has no
effect on the final model; smooth triangles are just a lighting trick.

For 3-D printing (extruding) hi-contrast artwork from a single image, the
slicing-and-3D SLICER steps are not really necessary; this can be done in your
printer's software instead. (I currently use Ultimaker CURA.) But from my
experience, the extruded object ends up with slightly non-parallel vertical
surfaces-- like a cone--for unknown reasons. A 3D SLICER trick works better, in
my opinion. (Due to the way it builds an object as voxels, multiple images are
needed, at high resolution.) The original image first needs to be *reversed* or
inverted right-to-left; then simply copy that image numerous times and re-number
the series consecutively for 3D SLICER use. The number of images determines the
extrusion height. (Note that Windows' 'Rename' feature can be used to re-number
a lot of images all at once.)

It should be noted that there is a difference in 3D SLICER's
'voxel-to-triangle' .stl process vs. how a typical triangle mesh is generated--
because the model is first built from cubic voxels rather than being a more
straightforward triangle conversion from the image pixels. In other words,
cubes-converted-to-triangles. Generally speaking, this will not unduly affect
the final 3D-printed model appearance when using hi-rez slice images and some
'smoothing' in that app.

Post a reply to this message

Attachments:
Download 'slicing_code_for_3d_printing_kw_4_2024.pov.txt' (12 KB)