"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> another installment in the long-running desire to have native stl support
> for POV-Ray.  There was some insistence that .stl is a binary-only format, or
> that it would be difficult to adapt our mesh {} code to handle stl.
>
> So the point is that if the SDL and stl are virtually identical, then it ought
> to be fairly simple to add the ability _in source_ to #include "MyModel.stl"
>

This entire discussion interests me greatly! And it finally shook me out of my
lazy doldrums. (Real-life took over this summer-- work, plumbing problems, and
more dental problems.) Anyway...

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.

Kurtz's ascii-STL-to-mesh conversion-- vial a Perl script-- is an amazingly
successful piece of code, and very elegant. The excellent mesh result speaks for
itself. 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.

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.

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.

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.
------------
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.

Post a reply to this message