Thomas de Groot <tho### [at] degrootorg> wrote:
> I have been wondering if some dedicated POV-Ray projects could somehow
> be 3D printed...

I played with this some years ago:

http://news.povray.org/povray.general/message/%3Cweb.5682a213e23216e08da727310%40news.povray.org%3E

This post was even replied to by Kenneth himself. Lurkers of the world unite!

Bill

Post a reply to this message

"Bill Pragnell" <bil### [at] hotmailcom> wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> > I have been wondering if some dedicated POV-Ray projects could somehow
> > be 3D printed...
>
> I played with this some years ago:
>
>
http://news.povray.org/povray.general/message/%3Cweb.5682a213e23216e08da727310%40news.povray.org%3E
>
> This post was even replied to by Kenneth himself. Lurkers of the world unite!
>

Hi all; sorry for my silence (yet again!) I have been working on a scheme to
turn a POV-ray object into a 3D-printable .stl file-- ANY kind of object or CSG,
not just a mesh or mesh2.

From what  I've read in the  previously cited newsgroup posts here, they all use
POV-ray's trace(...) function to create a dense 'point cloud' of an object,
which is then ported over to Meshlab or Meshmixer to re-build the object as a
triangle mesh and to create an .stl file for 3D printing. That apparently works
well for some objects, but I can see that just about any tracing scheme will
have some limitations and difficulties-- with overhangs and undercuts, for
example, and hollow spaces/holes.

So I decided to go about it in a different way: 'pre-slicing'  the object within
POV-ray as a series of thin slices (.png rendered images, white against a black
background), then importing them into an app called '3D slicer.' It's a huge
(230 MB zipped!) professional-level viewer/manipulator for hospital CT/MRI
scans. Take a look here...

https://www.slicer.org/

It is free to download, which is quite amazing, and can import a stack of .png
or .jpeg images (the slices) to recreate the object. It can also output an .stl
file, for later importing into your favorite 3D-printer 'slicer' software such
as Cura, Prusa-slicer, Creality Print etc. (They turn the .stl file into the
final .gcode instructions for the printer.)

This app is very intimidating and mysterious at first glance, and the GUI and
its menus are somewhat non-standard.  I spent a week researching various
medical-tech videos on Youtube to figure out HOW to use and navigate even the
basic necessary menus, as the layout is not newbie-friendly (and is designed for
a totally different audience). The processing steps we are interested in are
complicated to explain in words, but luckily use only a very small subset of the
app's vast list of features. Once the few required steps are learned, it's easy!

So the whole process is like this:  pre-slice the POV-ray 3D object -->  rebuild
the object as 3D from the slices -->  output the .stl file -->  re-'slice' the
model as .gcode for 3D printing.  It's a roundabout way of accomplishing the
goal, I admit, but it works! I have already printed several test models in PLA
plastic.

I will try to put together a how-to explanation of the process as it relates to
POV-ray.

Post a reply to this message

On 11/6/23 07:56, Kenneth wrote:
> I will try to put together a how-to explanation of the process as it relates to
> POV-ray.

It would be cool to see pictures of your printed stuff too when you have 
it going.

I'm reminded the other Bill P. never mailed me any of his printed 3D 
objects printed in gold. I wanted to carefully review gold printed 
objects - over some significant number of years. How well do they hold 
up? Do they melt down into nice small bars?

Bill P.

Post a reply to this message

Hey - very cool.
Glad you're having fun with all of that.

I've used Slicer in the past for 3D printing - but I think what you've also done
is come up with a (long-sought after) way to turn a complex object into a mesh.

If we could (semi-)automate the whole process, then we could model something
using CSG, then using animation - slice it up,  and send it through the
stacking-meshing pipeline, and then save the mesh for future use.   Doesn't
matter how slow it is, since the idea would be to have the object quickly
renderable in future scenes.

- BW

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Hey - very cool.
> Glad you're having fun with all of that.
>
> I've used Slicer in the past for 3D printing - but I think what you've
> also done is come up with a (long-sought after) way to turn a complex
> object into a mesh.

How long and painful was your learning curve with that app? When I first fired
it up on my computer, I thought "Holy s**t, how am I ever gonna understand this
thing?" The various online video tutorials I've studied were a godsend-- but I
still haven't come across one that clearly explains how to take image 'stacks'
and output an .stl file from them; I had to muck around on my own to discover
that little set of operations (which were not at all obvious, *groan*). The
online manual wasn't very helpful.
>
> If we could (semi-)automate the whole process, then we could model something
> using CSG, then using animation - slice it up,  and send it through the
> stacking-meshing pipeline, and then save the mesh for future use.   Doesn't
> matter how slow it is, since the idea would be to have the object quickly
> renderable in future scenes.

Right. Once '3D slicer' creates the model as .stl, it could be brought into
Poseray (and/or Meshlab?) -- I assume-- to convert it into a mesh file that's
usable for importing back into POV-ray, if needed.

One neat thing about my current process is that a complex model would probably
need supports placed here and there, for the 3D-printing step. Those supports
could actually be designed into the model in POV-ray (temporarily) which then
show up in the initial .png 'slices' just like the model itself, and become part
of the created .stl file ready for printing. To me, that seems a better way of
doing it than relying on the final 'slicer' software (Cura et al) to figure out
where the clunky supports should go. I haven't tried the idea yet, though; I'm
still in the early stages of 'discovery' ;-)

Post a reply to this message

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

> How long and painful was your learning curve with that app?

Well, I was working with someone who had already figured it out, and tbh, I
didn't personally use it much - and it was quite a long time ago.


> Right. Once '3D slicer' creates the model as .stl, it could be brought into
> Poseray (and/or Meshlab?) -- I assume-- to convert it into a mesh file that's
> usable for importing back into POV-ray, if needed.

STL are files are essentially _already_ mesh files.   They just use different
keywords to denote the triangles.  I wrote my own spreadsheet (and IIRC, so did
Cousin Ricky) to convert STL to POV - but perhaps a macro or something could be
written to do the absolutely trivial "conversion".  I'm still gobsmacked that
such a thing isn't already a solid part of the POV-Ray toolkit.
Actually, I'm shocked that no one has simply implemented direct import of stl
files by POV-Ray itself, since it would be "just" ;) a minor cut-and-paste and
then a little modification to handle the slightly different file structure.

<HINT> A sure candidate for immediate addition to the yuqk fork </HINT>
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> One neat thing about my current process is that a complex model would probably
> need supports placed here and there, for the 3D-printing step. Those supports
> could actually be designed into the model in POV-ray (temporarily) which then
> show up in the initial .png 'slices' just like the model itself, and become part
> of the created .stl file ready for printing. To me, that seems a better way of
> doing it than relying on the final 'slicer' software (Cura et al) to figure out
> where the clunky supports should go. I haven't tried the idea yet, though; I'm
> still in the early stages of 'discovery' ;-)

Support material is tricky.
I've written G-code from scratch, which is what handles the CNC aspect of
driving the printing head - it's truly not that difficult.
Which leaves me wondering why some of the printing patterns, and construction of
support structures seems so poorly implemented.

- BW

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> STL are files are essentially _already_ mesh files. They just use different
> keywords to denote the triangles.  I wrote my own spreadsheet
> (and IIRC, so did Cousin Ricky) to convert STL to POV - but perhaps a macro
> or something could be written to do the absolutely trivial "conversion".
> I'm still gobsmacked that such a thing isn't already a solid part of
> the POV-Ray toolkit. Actually, I'm shocked that no one has simply
> implemented direct import of stl files by POV-Ray itself, since it would
> be "just" ;) a minor cut-and-paste and then a little modification to
> handle the slightly different file structure.
>

Intrepid (and naive) experimenter that I am, I tried opening an .stl file in
Wordpad to see what would happen-- thinking that it *might* just be a simple
ascii text file (ha!) NOPE! A bunch of computer-ese gibberish instead. (Well,
the one I tried was a binary file, made in the Meshmixer app, so I should have
expected that.) The process of converting .stl to mesh2(?) for rendering in
POV-ray would seem quite daunting to my inexperienced eyes. Kudos to you and
Cousin Ricky for working that out.

>
> Support material is tricky.
> I've written G-code from scratch, which is what handles the CNC aspect of
> driving the printing head - it's truly not that difficult.
> Which leaves me wondering why some of the printing patterns, and
> construction of support structures seems so poorly implemented.
>
I'm finding that gcode is quite fun to play around with-- it's just simple text
commands. It's somewhat new to me though, so I'm being *very* careful when
attempting to edit my 3D-printer files. But the 'slicer' software for printers
seems to be quite an amazing coding accomplishment, turning .stl triangle data
into layer-by-layer .gcode instructions that delineate geometric paths; it seems
like magic. I guess old-style computer plotters used similar translation
algorithms(?).

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> Hi all.
>
> I've been away from the newsgroups for at least 6 months(!). Mostly work-related
> and seasonal--I play the guitar in a local band, and the Summer months have been
> hectic in this resort area. I also came down with Covid-- first time, and
> fortunately a relatively mild case; then my car had a major and mysterious
> engine problem that took several months to track down and repair (with no real
> mass-transit system available here); then I had an emergency medical situation:
> a kidney stone -- my first one!-- which had to be removed via laser-zapping;
> THEN I broke part of a tooth! But on a brighter note, several weeks ago I bought
> my first 3D printer, which I've been playing with constantly to discover the
> finer points of printing with it.
>
> It has been an interesting 6 months! But I haven't forgotten POV-ray; I've been
> working on several projects that I hope to post about soon.
>
> Meanwhile, I need to catch up on all of those neglected newsgroup posts.
>
> Cheers!

Dang...that's quite the series of events. I'm glad you made it through all that.
I
took the summer of from POV too. Just getting back to it in the last few days.
Best regards,
Mike.

Post a reply to this message

I have been working and developing on this tool of mine for a long time.
It is especially useful to me for 3D printing. I don't send executables around,
because the software environment is bad and I don't want to get involved in
virus mishaps. However, if it is useful to anyone, I can send them the source
code file, written with RapidQ (a good Basic) and completely autonomous in a
single file.
However, I start from CAD or STL, so it is advisable to transform only the POV
and INC (meshes blocks by colors) files that it has created. Because the syntax
of POV is large and complex. It
works only with 3DFACE and manages colors using Layers. It is often useful when
creating STLs to keep some parts in another color visible and separate.
BR
G.

Post a reply to this message

Attachments:
Download 'clipboard01.png' (22 KB)

Preview of image 'clipboard01.png'

On 2023-11-06 16:25 (-4), Bald Eagle wrote:
> 
> STL are files are essentially _already_ mesh files.   They just use different
> keywords to denote the triangles.  I wrote my own spreadsheet (and IIRC, so did
> Cousin Ricky) to convert STL to POV - but perhaps a macro or something could be
> written to do the absolutely trivial "conversion".

I have never converted STL to anything.  I have plugged numbers from SVG
files into a spreadsheet to re-scale its dimensions, then manually
copied the new dimensions into POV-Ray.

I would be more likely to use C, XSL, or awk than a spreadsheet to
convert STL.

Post a reply to this message