Le_Forgeron <jgr### [at] freefr> wrote:

Hi Jerome,

> You can always use a converter for STL from Ascii to Binary, it will be
> far simpler than having yet another extension of the parser, or even a
> dedicated parser. It's only once you have experimented handling the
> versatility of text input that you start to like strict binary encoding.

I'm not sure if I misunderstand you, or you misunderstand me.
I'd like for POV-Ray to be able to natively parse and implement a simple ASCII
stl file.

No one out there writes include files for POV-Ray in its mesh {} format.
But there are tens of thousands, if not millions or billions of stl files for
the exploding 3D printing community.
We don't currently have a modeler - but we have a ready made source of MODELS.
And obviously modelers to make stls.
Please tell me that I don't have to explain the obvious advantage of that any
more.

Being able to use an ASCII stl file by way of a simple #include statement would
be a profoundly useful tool for the user community.  And it would also act as a
tool to draw new users into POV-Ray, because we could make them aware of a new
(to them) tool that can digitally represent the model that they want to build,
or paint, or whatever.  More exposure = more users = more interest = more
exposure .... until we hit that threshold where some of the people who discover
POV-Ray _ARE_ software developers and we can get new people who are motivated
enough and competent enough to work on the source code.  And that brings along a
whole new source of new ideas and approaches to old problems that we may not
have thought of, and may not have been available until now.


> Somebody seems enthusiast about mesh... you have probably no idea yet of
> the nest of snakes you are to discover.

I'm not very enthusiastic about meshes (at the moment) but I do acknowledge that
there are good things about mathematical primitives - and severe limitations,
and the same goes for triangle meshes.

> mesh{} and mesh2{} are two syntax for the same final data structure, but
> the latter is far faster to parse when the number of points starts
> increasing, as the computation are in mesh2{}, whereas mesh{} just do it
> on the fly for you.

Yes Sir - I have coded scenes using both of those data structures, and so have
read (mostly) all of the applicable documentation.

> Never forget portability & universality. Povray could run on Amiga.

I'm not forgetting that at all.  At the same time, whether good or bad - the
Amiga days are long past, and if POV-Ray is to avoid stagnation and death, then
there needs to be a certain amount of innovation and modernization so that it
can leverage as much of the newer computer architecture developments as
possible.

I've learned a lot over the past 10 years, but I'm still not a computer science
major or software developer.  However, sometimes that's an advantage, because
I'm not restrained by any preconceived notion of "you can't do that!" and so I
find some crazy way to make things happen anyway.  ;)

I do understand that POV-Ray's primary means of rendering is not rasterization,
and does not rely primarily on triangles, but surely we may in some (other) way
take advantage of the massive parallel computing of GPUs.  I don't know what we
have in our codebase that would take advantage of that, but just experimenting
with the capability to access a GPU would be like tasting a new food.   Why do
it?  So that you know what it's like.  There's no other way to accomplish
gaining that knowledge.  Then you can proceed from there.  Maybe we like the
taste of GPU, maybe not.

I also stumble across all manner of ways that other people do things, and just
recently read of "just in time" compiling - so maybe that's something to discuss
for future development work.

(Good to see you again, we miss you here)

- BW

Post a reply to this message