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