Ilya Razmanov <ily### [at] gmailcom> wrote:
>
> This may be an interesting idea, assuming I can understand that format
> (do I understand it right that you printer requires some STL, and that's
> that STL I'm reading about at
> https://en.wikipedia.org/wiki/STL_(file_format) ?). Sounds like they
> have a text version of it.

Yes, the 3-D printer's software requires the final object to be in the .stl file
format-- either as a text file or a binary one. The 3D SLICER app can only
export it as a binary type, but that can be brought into another app like
Meshmixer to change it to a text file. However, the binary version results in a
much smaller file size. The Wikipedia entry is using the text version as an
example there.
>
> The problem I see right now is that we have different number of "outline
> pixels" at every section. Other than that, idea of slicing any object
> into set of planar sections, then reconstructing from this looks brutal
> ;-) But the problem is, the number of control points change between
> sections (sometimes they completely disappear), and I don't see a way to
> figure out how to deal with it.
>

Yes, it is a mighty big problem to try and solve! (3D SLICER's algorithm changes
them into voxels first-- somehow. But even there, the ultimate voxel-to-triangle
conversion can be a bit...strange... when individual 'naked' voxels are
processed that do not have surrounding neighbors.)

> ...on the other hand, if you dissect 3D with planes, who can stop me
> from further dissecting 2D slices thus obtained with scanlines? That may
> be it...

YES, that is the general idea I have as well. I am going to write some quick
'demonstration' scanning/eval_pigment code to see if I can make it work-- on at
least ONE sliced image. I *should* end up with another image that has just a
white-pixel shell, at only the outer surfaces of the white object as well as at
holes and voids.

This is just an interim step while I continue to think...  ;-)

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> 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!
>
> [BE:]
> Notice also that you don't have any holes in a heightfield.
> Try to make a surface from a photo of Swiss cheese, and you'll begin to
> appreciate what the problem is.
>
> In 3D it's even more challenging, because you have internal voids that
> you need to find and be aware of.
> [snip]
> So, there are a few challenges that need to be addressed - the first is
> where is the object and where is it not?  Trying to do that with trace () is
> going to fraught with problems.
> [snip]

Agreed. Your comments are a masterful analysis of the problems involved...and so
quickly! You amaze me.

I was thinking more along the lines of taking the already-made slice images and
using *those* as the basis for further pixel-to-triangle conversion (somehow),
thereby eliminating the scanning problems inherent in tracing the actual object
with inside/outside tests or whatever. The images have nicely-defined
black-to-white transitions, even for holes, undercuts, and internal voids.
Further processing of those images could(?) get us a nicely-defined *shell* of
white pixels at all the required locations-- for the then-MAJOR task of
conversion to triangles. That's my half-formed (half-baked?!) idea so far.

> Then once you accumulate all of the scan data, you need to address the issue
> of _connectivity_, and I, jr, and other can tell exactly how non-trivial
> a problem THAT is.

Yep, I'm beginning to see the problems now-- even the most fundamental one of:
What should each image pixel represent as a triangle conversion? One triangle?
Multiple ones? POV-ray's internal height_field-from-image algorithm uses 4
neighboring pixels to create... two triangles. A similar scheme may or may not
be appropriate, I don't know.

There is also the problem of 'handed-ness' for each triangle-- that is, which
triangle should have clockwise or counter-clockwise ordering of the three vertex
points (which determines the single face-normal required for each final.stl
triangle, to determine which direction it should face for printing.)
>
> Now, your mention of heightfields, and my armchair consideration of those,
> gave me an idea.
>
> The concept is this:
>
> Let's say you take your slicer method and you now have a slice.  One could
> scan the "image" with eval_pigment and see what's white and what's black. The
> position where you switch from one color to the other is obviously an edge.
> That would be a triangle vertex. Once you had all of your slices processed
> into a point cloud of vertices, you
> could scan through it and whatever points were close enough to each other in
> different layers, you could connect into triangles.
> [snip]
>

We're thinking along the same lines ;-)

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> [In 3D SLICER STEP 3-- The 3-D preview, and exporting the .stl printer file]
>
> 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.
>

I forgot to mention that 3D SLICER automatically appends 'Segmentation' to the
beginning of the exported .stl file name. So it will be saved as either
              Segmentation_Segment_1  (the default)
or
              Segmentation_ ... your chosen file name...

Post a reply to this message

On 08.04.2024 0:24, Kenneth wrote:

> Yes, it is a mighty big problem to try and solve! (3D SLICER's algorithm changes
> them into voxels first-- somehow. But even there, the ultimate voxel-to-triangle
> conversion can be a bit...strange... when individual 'naked' voxels are
> processed that do not have surrounding neighbors.)

I don't see much problems in turning layers of pixels (which you have 
already) into voxels. What as to turning this voxel volume into surface 
mesh - that's where the problem is. I took a quick look at some stuff 
used for this in scientific area - it's definitely not a simple trick I 
was thinking of. Still, I promise to think of a simple trick some more :-)

> least ONE sliced image. I *should* end up with another image that has just a
> white-pixel shell, at only the outer surfaces of the white object as well as at
> holes and voids.

Well, turning BW slice into BW contour is, most likely, not a big 
problem (going to try some ideas when I have more time), but I'm 
thinking of making some external program rather than using POVRay for 
that. With POVRay, I'm not so much experienced with SDL to see the solution.

"But we keep our experiments going, for human health is our primary 
goal" (c)

Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

On 08.04.2024 1:46, Kenneth wrote:

> Yep, I'm beginning to see the problems now-- even the most fundamental one of:
> What should each image pixel represent as a triangle conversion? One triangle?
> Multiple ones? POV-ray's internal height_field-from-image algorithm uses 4
> neighboring pixels to create... two triangles. A similar scheme may or may not
> be appropriate, I don't know.
Hehehe, as I've told once already, in my simple img2mesh program:

https://github.com/Dnyarri/img2mesh

I use 1 pixel to produce 4 triangles ;-) That is, it replaces 1 pixel 
with a pyramid of 4 triangles. No slow and memory-hungry tesselation but 
perfect match of pyramid's corners pretty fast :-)

Besides, I guess resulting structure will be compatible with stl specs. 
I will definitely check this out as soon as I get more spare time for 
programming. If it works, it will mean that at least I know how to write 
stl so I may turn to thinking of main task finally ;-)

Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

On 06.04.2024 14:24, Kenneth wrote:
> 
> 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.

Ok, thinking of cheaper modifications to STL producing process, I 
decided to make an STL-producing version of my previous PNG heightfield 
to POVRay mesh converter:

https://github.com/Dnyarri/img2mesh

I just uploaded img2mesh-STL.py file there, so anyone having Python 
installed may give it a try. No compiled exe so far, since it's just 0.1 
version supposedly having unknown number of unknown bugs. This is why 
I'm quite interested in feedback from people using real 3D printers. So 
far I checked resulting .stl file for compatibility with several viewers 
and tried some 3D printing software called UltiMaker Cura 5.7.0, all 
were able to successfully open my .stl files. However, I'm still not 
sure that it guarantees successful printing, so, again, I will much 
appreciate testing and feedback.

Now, going back to Kenneth's idea of slicing: I thought that perharps we 
can replace complete interpolation of slices and tesselation with some 
POVRay interpolation, that is, instead of black/white sections of object 
use sections with height-gradient pigment, then use resulting PNG 
rendering as heightfield for conversion into triangle mesh.

Surely, it will work only with "visible" half of the object; I still 
haven't figured out universal solution but that printing software seem 
to be capable to import several .stl and then place it on top of each 
other. Maybe, in combination with Kenneth's slicing but in gradient 
variant, this will allow assembling complex objects.

Ok, my typing resources seem to be exhausted for today, right next to 
thinking ones. May be later.

Again, I would be very grateful for testing and finding issues.

-- 
Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

The attached image shows the nature of 3D SLICER's voxel-to-.stl-triangles
construction scheme on an enlarged scale, with and without 'smoothing' used
there. The same number of triangles are created either way.

I purposely sliced a POV-ray cone object at a very *low* resolution, 50 X 50
pixels with 50 slices.  The exported .stl file is shown in Meshmixer and
Ultimaker CURA. Note that on curved exterior surfaces, the voxels join to their
neighbors with a 45-degree tilt of triangles. In my opinion, this is an
advantage-- the surfaces are not simple 'stacked boxes'. With *high*-resolution
image slices, those tilted triangles become so small that even sharp model edges
are retained.

The tip of the cone ended up as four voxels, not one; that was my mistake with
the image resolution I chose. 51X51 pixels would have produced a single-voxel
tip, I think.

This particular cone object illustrates an interesting fact about the slicing
scheme itself, and how it relates to 3D SLICER. In POV-ray, the cone was made
with a 1-unit diameter base and 1 unit tall--- which happens to result in an
exactly cubic bounding box there, behind the scenes. Since it *is* a cube, the
slicing image dimensions and number of slices should be in a 1:1:1 ratio-- for
example,  500X500 rez with 500 slices (assuming the object 'fills the view' in
the renders). POV-ray's messages pane is not really needed to get the proper
ratio in this case-- the result would be a perfectly-proportioned cone due to
the automatic camera in my slicing code.  The same would happen with a sphere--
a cubic bounding box again. This little fact initially confused me as to how the
app was processing the *number* of slices I made-- my test objects had
different-sized b.b.'s with just a few being cubic by chance, and I didn't
realize the significance of the difference at first.  It's fundamentally because
the voxels in 3D SLICER  are 1mm cubes themselves, by default. But most objects
will have an oblong bounding box, not cubic-- which affects the number of slices
required, as each slice represents a single voxel's height. The wrong number
distorts the model.

Post a reply to this message

Attachments:
Download 'low_rez_3d_slicer_example_kw_4_2024.jpg' (915 KB)

Preview of image 'low_rez_3d_slicer_example_kw_4_2024.jpg'

Ilya Razmanov <ily### [at] gmailcom> wrote:
> On 08.04.2024 1:46, Kenneth wrote:
>
> > Yep, I'm beginning to see the problems now-- even the most fundamental one of:
> > What should each image pixel represent as a triangle conversion? One triangle?
> > Multiple ones? POV-ray's internal height_field-from-image algorithm uses 4
> > neighboring pixels to create... two triangles. A similar scheme may or may not
> > be appropriate, I don't know.

> Hehehe, as I've told once already, in my simple img2mesh program:
>
> https://github.com/Dnyarri/img2mesh
>
> I use 1 pixel to produce 4 triangles ;-) That is, it replaces 1 pixel
> with a pyramid of 4 triangles.

Aha! YES, I remember reading your post, but I forgot that your scheme has a
connection to the current problem! (I just read your latest post here as well,
about your .stl experiment; I need time to digest it.) Your use of 4 triangles
per pixel is something that I was considering as well...although I did not think
it through in detail like you did. Nice work! You mentioned that you used Python
for your experiments; I have to admit that I have not yet 'dipped my toes' into
learning it.

You might be interested in the attached image ;-)

This is what a single 'naked' pixel looks like as a voxel in 3D SLICER, using
zero 'smoothing' there-- actually 8 triangles instead of 4, and rotated 45-deg
around vertical. (I used Meshmixer to view the resulting .stl file.)  The
diamond shape occurs when there are no neighboring voxels to join-up with. To
create it, I made a single 1X1 pixel white image(!) and loaded that into the
app.  (Such a single voxel-as-.stl *can* be 3-D printed, by greatly enlarging it
in the printer's software.)

3D SLICER was apparently never designed to process pure white images or
CT-scans-- this tiny image does not show up there until my STEP 3 instructions
(in 'Segment Editor') are used to 'activate' it and show it as 3-D. (My
slicing code keeps a 1-pixel black border around typical much-larger slice
images, to eliminate this problem.)

A single line of *diagonal* pixels is an oddity-- there are gaps between the
created voxels because of their intrinsic rotated orientations, even though they
do still have a 1:1 size-correspondence with the image...but I wonder how those
gaps affect tiny details in medical CT scans.

And TWO copies of a single-pixel image -- as two 'vertical slices' so to speak--
end up as a horizontal unit of voxels, not vertical as I would have expected.
That is an anomaly in my opinion, but I guess the app's developers had a reason
for designing it with such behavior...or didn't foresee the possibility(?) My
single-pixel 'torture test' is rather extreme though!

Post a reply to this message

Attachments:
Download '3d_slicer_single_pixel_test_kw_4_2024.jpg' (168 KB)

Preview of image '3d_slicer_single_pixel_test_kw_4_2024.jpg'

On 11.04.2024 15:09, Kenneth wrote:
> 
> You might be interested in the attached image ;-)

Sorry, don't have much time for a complete answer - some job retracted 
me from experiments with single pixels and finding bugs ;-)

What as to your previous image, yes, it shows tessellation at work. 
That's a bit tricky stuff. Surely there are some ready-made libraries 
for that, but it takes time to just read about it - it's not an easy 
task (I mean tessellation. However, on the other hand, reading is too), 
that's why I though of some cheap tricks first.

What as to Python, I'm only starting to look at it, so far I can say it 
definitely helps me making mistakes faster (that is, I don't have to 
wait for a long compilation to discover that I made yet another mistake) ;-)

-- 
Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

So after you have generated your STL files, have you tried editing them to see
how that works out?
Repaired / retriangulated the mesh?

Also, I have an STL file that I need to edit (enlarge a USB connector hole) - do
you have any recommendations for a good STL editor (free).

- BW

Post a reply to this message