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

> Having ascii-STL-to-mesh (or mesh2) conversion built-in 'under-the-hood' would
> be a great addition to POV-ray. But since v4.0 is still a long way off(?), some
> kind of STL-to-POV-ray-SDL conversion script would be *most* welcome.

That said, if someone could provide a road map for what we need to do to write a
PATCH, then it could simply be added by unzipping a folder of the required
files, and ADDING the feature to the existing 3.7/3.8

>I don't know Perl, but I am *almost* convinced that a similar piece of
> code could be written directly in POV's SDL, using #read and #write, because the
> syntax used in typical STL files is so simple. The conversion code would
> probably not be as elegant as Kurtz's, but that's a small price to pay.

SDL sucks for this kind of thing, mostly because we don't have any way to read a
piece of data from a random file, determine what data type it is, and then run
conditional code.
All strings need to be quoted, we need commas, etc.
So, some sort of pre-processing script would need to be run first.
And if you're going to do that, why do it in SDL at all?  Just do it in the
preprocessing language.

> Speaking of simplicity, I would argue that converting to a mesh (rather than
> mesh2) would be the way to go-- as in Kurtz's result.  It's much simpler to
> implement, AND much simpler to edit afterwards, should the need arise. The mesh2
> format and syntax is more 'abstract', and the docs' example of how it works (and
> how to write it successfully) is lacking...although the necessary understanding
> can be teased-out (with help from Wikipedia :-) -- at  "triangle mesh", under
> 'index arrays'.) But I think that a simpler 'mesh' construct would be easier to
> create from an STL file,  when using #read/#write.

I have written both from scratch, and might have some code to assemble each
primitive from a collection of triangles kicking around somewhere.
It's basically a problem of connectivity.  One can take the raw triangle data
and search for common vertices to see what triangles share edges, and build up
the data structure that way.

I'd favor conversion to a mesh, with the option of taking the resulting mesh and
making a mesh2 as an optional function to invoke separately.

Also no reason we couldn't just distribute such scripts in some sort of utility
directory with the distro.

> Mention was made here of possibly adding 'normals' to the resulting mesh
> conversion-- which I take to mean, converting the triangles to 'smooth
> triangles', so that curvy surfaces appear smooth in the POV-ray render, rather
> than as the original STL flat-triangle 'facets'. But that may not produce the
> intended effect for an *entire* model, as there could be smooth areas as well as
> sharp angles and corners. Kurtz's "att.low.jpeg" example image shows such a
> model. (The visual smoothing effect would depend on the triangle resolution, of
> course.) The problem is that, in an STL file, there is no way to know which
> triangles should be 'smoothed' and which should not; they are all just flat
> facets.

Very true, thus the continuing need for a modeler.

> An alternate scheme would be to slightly alter the vertex positions of all of
> the flat triangles, to produce a somewhat similar smoothing effect in the POV
> render...although I have no idea as to how that is accomplished, algorithm-wise.

Subdivision.  Plus some interpolation code for the new vertices to follow the
smoothed edge.

> Kurtz's posted file package here has the original STL 'crate' model from
> Thingaverse. That model actually has a few minor triangle (or normal?) flaws,
> when seen in Meshmixer (and when 3-D-printed via CURA software; I printed a
> small section of the crate, just to see.) I have noticed this in other
> Thingaverse files as well. Apparently, no check is made of uploaded models
> there, to make sure that the models are 'robust' and completely correct.

Determining the correct normal direction for any given triangle can certainly be
challenging.  It's probably the most difficult part of writing a modeling
software. I'd say you could probably run a check of all the neighboring
triangles and if all of the neighbors are within some given angular range of
each other, but the triangle you're checking is 180-range, then flip it.

Lots of articles and algorithms on the web covering this topic.

- bw

Post a reply to this message