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)

An image to help with the POV-ray slicing...

Post a reply to this message

Attachments:
Download 'object slicing in pov-ray kw 4_2024.jpg' (322 KB)

Preview of image 'object slicing in pov-ray kw 4_2024.jpg'

3D SLICER automatically starts up in its 'Welcome to Slicer' view; the attached
image is the start-up screen, with my annotations (as it appears in Windows 10.)
It's a large app, so give it time to load. You should see four blank view-panes
to the right.  If not, go to the top row of icons and choose the 'Four-up'
working view from a pull-down menu.

The large 'Add Data' button on this opening page will be used to import your
previously-rendered image slices.

Only THREE of the app's core 'modules' will need to be used for the entire
process, and in a simple way:
    'Welcome to Slicer' (the first module)
    'Volumes' (which is optional)
    'Segment Editor'

(The 'Welcome to Slicer' icon at the top has a menu; we will use that later to
choose the other modules.)

In this screenshot and those to follow, only the details with my annotations are
important; the rest of the app's features can be ignored.

Post a reply to this message

Attachments:
Download '3d slicer startup view.jpg' (215 KB)

Preview of image '3d slicer startup view.jpg'

3D SLICER app-- STEP 1: importing the image slices

See the attached image as a guide.

(If you find that something does not appear to work correctly or if you make a
mistake, simply go to the main 'File' menu at top, choose 'Close Scene', and
start over.)

A) The large 'Add Data' button is used to import the slice images. The window
that comes up needs to be expanded left/right on your monitor, to see some of
the details that will eventually appear.

B)  Click on 'Choose file(s) to add', and search for the folder with your slice
images. When you click on that, the slices will appear in a separate window.
Click on the first image there, and then 'Open'. That window will close, and the
first image's file path will appear in A)'s still-open window.

C) Click the small 'Show Options' box in that window in the upper right corner,
which brings up more choices. Then *UN-check* the 'Single file' box, and hit
'OK'.  Give the slices time to load.

The slices will show up as the re-created model! In three orthographic views (no
3-D view yet). The sliders at the top of the three view-panes can be used to
cycle through the slices/voxels.

(3D SLICER does not use conventional x,y,z axes for the view-panes-- or even
up/down, left/right-- but medical terminology instead. The individual views'
orientations depend on the original POV-ray camera direction, which was looking
up from below. In the attached image, I have re-labeled the view-panes to make
them understandable.)
                    ---- END OF STEP 1 ----
Step 2 will follow...

-------------
If any of the three object-slice previews seems to disappear, right-click on the
view to bring up a menu; choose 'Reset field of view'.

For moving the camera around in the orthographic view-panes (and later 3-D
preview):
GLOBAL ROTATIONS around the centerpoint:  left mouse button click/drag (3-D view
only)

ZOOM: right mouse button click/drag

ROTATING clockwise/counterclockwise: Ctrl+left mouse button click/drag (3-D view
only)

PANNING up-down/left-right: Shift+left mouse button click/drag

Post a reply to this message

Attachments:
Download '3d slicer step 1-- importing the images kw 4_2024.jpg' (449 KB)

Preview of image '3d slicer step 1-- importing the images kw 4_2024.jpg'

3D SLICER STEP 2-- the 'Volumes' module (COMPLETELY OPTIONAL)

At the  'Welcome to Slicer' icon (menu) at the top, choose the 'Volumes' module
instead. The window that appears has some interesting features.

At 'Active Volume', you should see the name of the first image slice you opened
previously. If not, 'Select a volume' there and  choose that image name from the
options. This opens a partial data field.

Look for a little checked 'interpolation' box; this is ON by default, and
slightly smooths the three orthographic views. You can turn this off the see the
raw image-slice pixels. This interpolation does NOT affect the (later) 3-D view,
or the final model output; it's just for previewing.

Now click on the little arrow at  'Volume information' to open its sub-menu. The
three  'Image Spacing' boxes that appear are for varying the default 1X1X1mm
voxel size of the app-- should you have a need for that, or to correct any
out-of-shape proportions of your model. Essentially, you can squash-and-stretch
the model here, and the three view-panes update automatically. However, this
simply stretches or distorts the individual voxels-- and the final .stl
triangles; no new ones are created. (I think there is a slight bug when trying
to enter fractional values; the cursor caret does not behave well, compared to a
traditional word processor.)

         ------ END OF OPTIONAL STEP 2------

Post a reply to this message

Attachments:
Download '3d slicer step 2-- volumes-- optional-- kw 4_2024.jpg' (342 KB)

Preview of image '3d slicer step 2-- volumes-- optional-- kw 4_2024.jpg'

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