Hello,

Looking at the messages, I see that there are some specific versions for MAC OS.

I am not sure to understand. For MAC OS, I just download the UNIX version, which
is the same than the Linux one. Then I compile using the GNU environment, As I'd
do if I were working under Linux.

Is there a specific version of POVRAY for the Apple LLVM Compiler ?

Regards,

Denis

Post a reply to this message

denis.beurive <den### [at] gmailcom> wrote:
> Is there a specific version of POVRAY for the Apple LLVM Compiler ?

How would it be different?

(LLVM/Clang is just a standard C++ compiler, like gcc. What exactly would
be the difference?)

-- 
                                                          - Warp

Post a reply to this message

> Hello,
>
> Looking at the messages, I see that there are some specific versions
> for MAC OS.
>
> I am not sure to understand. For MAC OS, I just download the UNIX
> version, which is the same than the Linux one. Then I compile using
> the GNU environment, As I'd do if I were working under Linux.
>
> Is there a specific version of POVRAY for the Apple LLVM Compiler ?
>
> Regards,
>
> Denis
>

   Just curious... is there any reason why Yvo unofficial version doesn't
suit your needs? Or you just wanted to build it yourself?

--
Jaime

Post a reply to this message

Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:

> > Hello,
> >
> > Looking at the messages, I see that there are some specific versions
> > for MAC OS.
> >
> > I am not sure to understand. For MAC OS, I just download the UNIX
> > version, which is the same than the Linux one. Then I compile using
> > the GNU environment, As I'd do if I were working under Linux.
> >
> > Is there a specific version of POVRAY for the Apple LLVM Compiler ?
> >
> > Regards,
> >
> > Denis
> >
>
>    Just curious... is there any reason why Yvo unofficial version doesn't
> suit your needs? Or you just wanted to build it yourself?
>
> --
> Jaime

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

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> denis.beurive <den### [at] gmailcom> wrote:
> > Is there a specific version of POVRAY for the Apple LLVM Compiler ?
>
> How would it be different?
>
> (LLVM/Clang is just a standard C++ compiler, like gcc. What exactly would
> be the difference?)
>
> --
>                                                           - Warp

I don't know. I never used the Apple development tools. I always used GCC, with
open source libraries, even under MAC OS. I don't know anything about the
Apple's tools and libraries. May be I should have a look, since I installed
XCODE ;-)

Regards,

Denis

Post a reply to this message

denis.beurive <den### [at] gmailcom> wrote:
> I don't know. I never used the Apple development tools. I always used GCC, with
> open source libraries, even under MAC OS. I don't know anything about the
> Apple's tools and libraries. May be I should have a look, since I installed
> XCODE ;-)

There is no practical difference between gcc and clang. They both do the
same job.

(The differences are technical. They use different usage licenses and they
obviously produce different code. I don't know which one produces faster
code nowadays, but gcc probably still has a slight edge.)

-- 
                                                          - Warp

Post a reply to this message

denis.beurive wrote:

> I am not sure to understand. For MAC OS, I just download the UNIX version, which
> is the same than the Linux one. 

I have not used the mac version but I understand it comes with
a GUI like the windows version. Since you do not like GUIs you
are probably better off building from unix sources ;)

Post a reply to this message

"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