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