"jr" <cre### [at] gmailcom> wrote:
> >
> > So it's just a matter of read, discard, find/replace/rename.
>
> alternatively, you could take my 'stl2gts' and edit to output mesh[2] directly,
> instead.  fwiw, I'd prefer via GTS as it will allow manipulation of the
> (intermediate) data.  ;-)
>
> <https://news.povray.org/web.5e75678e7c21754451952ca0%40news.povray.org>
>

For those who don't know what GTS is (like me!), see this link. I'm just a lowly
Windows user, ha, with no Linux experience. I had to look it up. ;-)

https://occam.cs.pitt.edu/QmWKxta8pD5wrK76F1J2iRRP2kUwzZph5hqGRpCB6Vjpeq

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> Oh, and unfortunately, the '3D slicer' app outputs its .stl file in only the
> binary format; no choice of an ASCII version there  :-(  So far, anyway... but
> the developers are always adding new features to the app, from user feedback...

Since I am so new to this .stl and 3-D printer stuff, I *just* discovered that a
binary .stl file can be easily converted to a human-readable ascii TEXT file
(should you want to.) I used Audodesk's free (but no longer supported)
'Meshmixer' app for the conversion. There are probably other apps that can do
the same. Even though the file still has the .stl file type appended, it can be
opened by most(?) simple text editors, even POV-ray. I used Windows' simple
Wordpad app.

The text-file version is much larger than it's equivalent binary file, about 5X
larger. My CURA printer software can open both types.

Post a reply to this message

On 2023-11-16 14:06 (-4), Kenneth wrote:
> 
> For those who don't know what GTS is (like me!), see this link. I'm just a lowly
> Windows user, ha, with no Linux experience. I had to look it up. ;-)

I judge operating systems.  I don't judge their users.

> https://occam.cs.pitt.edu/QmWKxta8pD5wrK76F1J2iRRP2kUwzZph5hqGRpCB6Vjpeq

> License LGPL 2.0

Do the lawyers at OCCAM and the University of Pittsburgh know that there
is no such thing as the LGPL 2.0?

Post a reply to this message

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > fwiw, I'd prefer via GTS as it will allow manipulation of the
> > (intermediate) data.  ;-)
>
> For those who don't know what GTS is (like me!), see this link.

don't !  :-)  go straight to the source..
<https://gts.sourceforge.net/>


>  I'm just a lowly
> Windows user, ha, with no Linux experience. I had to look it up. ;-)

crosses to bear, and all that.  </grin>


regards, jr.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> This '3D slicer' app's capabilities immediately gave me the idea of
> 'pre-slicing' a complex POV-ray model as a series of rendered slice images via
> animation (using an intersection of a thin box object), to import into the app
> to see what the results might be.

[kind of off-topic/on-topic]:

I just discovered-- after all of my years of POV-ray'ing-- that this
intersection box for rendering object slices can actually be ZERO thickness. It
will still show the object slice at that 'infinitely-thin' plane. I already knew
that a box could be made like that-- but didn't expect such an intersection to
work.

A simple example:

intersection{
sphere{0,1}
box{<-1.1,0.2,-1.1>,<1.1,0.2,1.1>} // no y-thickness
}

-----
I have two different slicing schemes at present, to see which one
produces the better-recreated model in the '3D slicer' app: the zero-thickness
scheme above, or a thickness that depends on the number of animation
frames i.e. total slices rendered (which is what I have been using so far,
mostly.) Either scheme renders just 2-D white-on-black images of course, but
there *may* be a subtle difference in the result. More tests to do!

Post a reply to this message

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

> I just discovered-- after all of my years of POV-ray'ing-- that this
> intersection box for rendering object slices can actually be ZERO thickness. It
> will still show the object slice at that 'infinitely-thin' plane. I already knew
> that a box could be made like that-- but didn't expect such an intersection to
> work.

I've probably discovered such a thing simply because I've accidentally made so
many infinitely thin shapes before.  :D

> I have two different slicing schemes at present, to see which one
> produces the better-recreated model in the '3D slicer' app: the zero-thickness
> scheme above, or a thickness that depends on the number of animation
> frames i.e. total slices rendered (which is what I have been using so far,
> mostly.) Either scheme renders just 2-D white-on-black images of course, but
> there *may* be a subtle difference in the result. More tests to do!

I would say that your render settings such as image size ("resolution") and
antialiasing values will have more of an effect than anything.
Also, depending on what your texture and lighting values are.
For what you're doing, I'd go for an orthographic camera, NO light, and an
emission 1 white.

Another idea, just to play with variations on the theme is to do something
shader-like, and either use the object pattern or inside to make a function that
you apply to a plane perpendicular to the camera.
Then you can simply move the plane "through" the space that your (virtual)
object occupies and take infinitely thin "slices" pixel by pixel as the plane is
rendered.
Better yet would be to just texture a box, or two triangles delimited by the
bounding box of your object (or a slice of it), to keep function evaluations to
a minimum and speed render time.

- BW



inside(O,V)
It returns either 0.0, when the vector V is outside the object, specified by the
object-identifier O, or 1.0 if it is inside.


Something extra wicked-cool would be to find a way to use a software to "unwrap"
the skin of your object as a uv-map surface and just print a thin layer as
triangles that could then be folded up into a "skin" that is the outer surface
of your object.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:

> Another idea, just to play with variations on the theme is to do something
> shader-like, and either use the object pattern

Yes, this works

> or inside to make a function

No, this doesn't - because function parser strikes (out) again.

> Something extra wicked-cool would be to find a way to use a software to "unwrap"
> the skin of your object as a uv-map surface and just print a thin layer as
> triangles that could then be folded up into a "skin" that is the outer surface
> of your object.

So I had another idea while looking at some other code - use an edge-finding
kernel to process the "pixels" in the object pattern, and then by stacking those
shells (of sufficient thickness), you could just print a completely hollow
version!   :)

Not working so good atm, but maybe if everything got converted to SDF's or a
proper gradient, then that would work better.
Maybe make a hollow isosurface out of it and take (thickened) slices of that.

- BE

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> For what you're doing, I'd go for an orthographic camera, NO light, and an
> emission 1 white.

Yep, that is my current set-up. *Although*... That '3D slicer' app has some
interesting tricks among its more mysterious features, as I study and play with
it. To wit: Typical medical CT scans are basically grayscale files, from what I
have read so far. The various organs in the body produce different shades of
gray, depending on their density (and maybe other factors) as registered by the
X-rays from the rotating machine. There are controls in '3D slicer' to sequester
or specify which 'band' of gray that shows up as an object, and to eliminate the
other shades... essentially like the 'levels' and 'contrast' settings in
graphics apps. In fact, there are presets built-in for things like bones, etc--
based on some kind of accepted standard. SO, it would be possible to render
grayscale slices in POV-ray-- say, different grays for different parts of a CSG
object-- then use the app to 'remove' certain objects that you don't want to
print. Just an idea so far.
>
> I would say that your render settings such as image size ("resolution") and
> antialiasing values will have more of an effect than anything.

Exactly. In fact, the rez of the image slices seems to be more important than
the number of slices, for creating a sharp and detailed model. The many tests I
have made confirm this. I guess that's because the 3-D printing process is
mainly concerned with the quality of the outside shape-- in my case, the outline
of the solid white areas in the POV-ray images.

As far as antialiasing is concerned, I'm still not sure if it helps. AA is, in
effect, a tiny blurring of image pixels-- meaning grayscale in those tiny
areas-- and I don't yet know how '3D slicer' handles those. It's difficult to
see what effect it has on the final printed model, since the app's own
reconstructed model is so large that I have to shrink it down in the Cura
printing software...which 'tightens up' the quality and reduces any possible
oddness from the AA. But I am *still* making tests...and the printing process is
slow...
>
> Something extra wicked-cool would be to find a way to use a software
> to "unwrap" the skin of your object as a uv-map surface and just print a
> thin layer as triangles that could then be folded up into a "skin" that
> is the outer surface of your object.

I had the same idea! (well, at least the un-wrapping part.) So far, I haven't
seen such a feature in '3D slicer'... but that's not saying much! I have barely
scratched the surface of what it can do. It could probably make peanut-butter-
and-jelly sandwiches if I could find the controls...

Post a reply to this message

Another 3-D printed example-- all mathematical primitives again (but with a
height_field thrown in too).

I am still working on my step-by-step guide to using the '3D slicer' app for
this process, to make the few steps very easy to understand. Coming soon!

Post a reply to this message

Attachments:
Download 'pov_ray_to_printed_model_2_kw.jpg' (191 KB)

Preview of image 'pov_ray_to_printed_model_2_kw.jpg'

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> I am still working on my step-by-step guide to using the '3D slicer' app for
> this process, to make the few steps very easy to understand. Coming soon!

Well... here's something humorous (ironic?), in an irritating sort of way:

Tonight, I was *finally* finishing the first part of my how-to guide for using
the 3D SLICER app-- and discovered that an updated version has just been
released today! The previous 'newest' version that I've been using was released
in 2019. Now, I need to download the new one to see if my instructions and
screenshots are still valid. :-/  What strange timing!

Post a reply to this message