"denis.beurive" <den### [at] gmailcom> wrote:
> Hello,
>
> In fact I wanted to compile it myself because I want to study the code.
>
> I want to study the relation between the parser (that loads the textual
> description of the scene) and the renderer (that produces the image).
>
> I imagine, but I need to check, that :
> The parser produces some kind of "structured" representation of the scene.
> This "structured" representation is then given to the renderer.
>
> In other words, I want to find out if it is easy to separate the parser from the
> renderer. I assume it is, since the code seems pretty clean. But I need to look
> at it.
>
> I do that because I want to see how difficult it would be to write a binding for
> an interpreter such as Python, Perl, PHP or Ruby. That is : replacing the actual
> scene description language by another one (ie : Python, Perl, PHP or Ruby).
>
> Why ?
>
> For many reasons.
> This would allow the use of big frameworks. For example, I could integrate
> functions used to calculate geographic distances in the scene description (ex
> for Perl: GIS::Distance). Or I could use POVRAY to generate 3Ds output for
> anything (such as : the topology of my IP network).
> This would allow the use of sophisticated flow control. I mean : all we have in
> modern languages.
>
> Actually I use POVRAY like this :
>
> I write a template of POVRAY file.
> Then I write a Perl script that does the "complex calculation" (the "hard
> logic"), and fills the template with values. I do that with Perl, because I
> don't want to rewrite all the complexes functions that you can find in CPAN (and
> the POVRAY scene description language is no good for that).
> Then I call POVRAY on the generated POV file.
>
> Best regards,
>
> Denis

There is nothing wrong with generating povray code from other languages. I often
generate it using bash scripts (bash loops, sed, grep and awk), which wouldn't
benefit from a high-level API. Text interface is still the best for this use,
it's the most versatile, as it is universal.

Technically, the replacement of the parser is possible, but then the problem is
the following: if you want it to be a separate application, then you need an API
to transfer the scene description from parser to raytracer, and this means you
need an intermediate language (which would probably be just a binary version of
the existing scene description language - highly redundant). On the other hand,
you can compile everything into a library and simply call the constructors and
scene building functions from perl / python / whatever. But that is even worse.
You need to agree on the api. c++ has name mangling, layout of virtual classes
that would have to be implemented on the other side, and additionally, povray
code is changing, which would break all the alternative parsers in every version
(there code now is a messy mixture of 20-year old pieces of c and newer c++
class structures, so it will change a lot in the future). However, if the code
gets slowly rewritten and unified in the future, it would be a good opportunity
to be smart and make the interface abstract enough to allow easier replacement
of the parser.

Post a reply to this message