On Tue, 24 Mar 1998 18:02:49 +0200, Vahur Krouverk <vah### [at] fvaetecee>
wrote:

> 1. Create converter .inc=.pst ([P]OV-Ray [s]mooth [t]riangle). This
>would do following:

This step gets past my first argument, which is with the lack of a
truly standard floating-point representation.  By converting the .inc
file on the same machine on which you plan to render, the format
problem goes away.  But the conversion step will require that you
parse the mesh at least once.  That's probably still a big win for
most of us, since we rarely do only one render of a given file.

>  read (Rhino created)  .inc file. For each smooth_triangle declaration
>read triangle and export it's coordinates binary representation to .pst
>file (just 6x3x8 bytes for each triangle). All other lines export to new
>.inc file, which would look as follows:
>mesh{
>binary_mesh filename.pst
>texture{ ...}
>}

Meshes aren't just smooth triangles; they can also contain triangles.
That's not too hard to deal with.  Each triangle can have its own
texture, too, but textures are limited to untransformed, predefined
textures so you need only store the names of the textures and
reassociate them when you read the .pst file.

>2. Change POV-Ray parser to be able to read binary_mesh (my initial idea
>was to copy double from file to given memory area, but may-be it is
>possible to read mesh from file directly?).

The mesh also contains an internal bounding-box heirarchy, so being
able to read it as a big chunk would be a good thing.  The texture
thing might mess this up, however.

>Is this idea feasible? Is anybody out there with enough resources and
>time to try this out? 

I think it's feasible.  I wish I had the time to finish the POV
programming projects I'm already working on.

Post a reply to this message