Le_Forgeron <lef### [at] freefr> wrote:
> Le 20/12/2012 10:46, denis.beurive a écrit :
> > Hello,
> >
> > First: English is not my mother language. I do my best to be clear. One way to
> > make sure that my message is clear is to reformulate my sentences.
> >
> > I did not look at the code yet. But I ask myself two questions :
> >
> >
> >
> > ### Question 1 :
> >
> > Would it be difficult to separate the renderer from the user interface ?
> > ie:
> > Would it be difficult to embed the function that reads the source code (that
> > represents the scene) and generates an image into a separate process ?
> >
>
> Nabla mu.
>
> You seems to have seen povray for Windows and not the unix version which
> is reduced to a command-line interface.
>
>
> >
> >
> > ### Question 2 :
> >
> > Are the parsing function (that reads the scene description) and the rendering
> > function well decoupled ?
> > ie:
> > Is the source code of the parser well isolated from the source code of the
> > renderer ?
> >
>
> Show us that you have spent more time on the subject than it would take
> some of us to answer in this thread.
>
> Get the sources (any version, 3.6 or the 3.7RC6) for unix and look at
> the files.
>
> I know the answer, but you are not ready for it.
>
> >
> >
> > ### Explanation for the first question :
> >
> > When porting a software, user interface is often painful. Furthermore, Povray's
> > user interface is essentially a code editor. It could be replaced by any serious
> > code editor, such Eclipse.
>
> If you are volunteer, povclipse project awaits your powerful brain and
> coding abilities to get updated and running with the 3.7 version of
> povray. IIRC, it's somewhere in sourceforge.
>
> > From my point of view, there is no reason to maintain the Povray's user
> > interface.
>
> De gustibus... (et coloribus non est disputandum)
>
> >
> > I guess that Povray does not use any OS dependant library for the rendering.
>
> Don't guess, look at the code and the compilation environment.
>
> >
> > We could see the renderer as a compiler.
> >
>
> Text in, image out... would you call latex a compiler ? (text in,
> document out). I would guess the right term would be a processor (as
> pre-processor).
>
> >
> >
> > ### Explanation for the second question :
> >
> > Povray's language for scene description is quite archaic (for today's
> > standards).
> > My impression is that it was first a "descriptive language" (such as XML).
> > Then variables and macros were added, to make it a very basic "programming
> > tool".
> >
> > If we can isolate the renderer code, we could interface it with languages such
> > Perl, Python, PHP... All the parsing and the hard work would be handled by the
> > (Perl, Python, PHP) interpreter. Furthermore, we could use the entire collection
> > of libraries available for these languages.
>
> Would it provide performance ?
> Would it provide distributed-rendering ?
>
>
> --
> A good Manager will take you
> through the forest, no mater what.
> A Leader will take time to climb on a
> Tree and say 'This is the wrong forest'.


OK, I've compiled POVRAY under Mac OS X 10.7.5.

Processeur  2,3 GHz Intel Core i5

Graphisme  Intel HD Graphics 3000 384 MB
Logiciel  Mac OS X Lion 10.7.5 (11G63)

The problem comes from the flag "-march", in the file "configure"?

On MAC :

-march=name
This specifies the name of the target ARM architecture.  GCC uses this name to
determine
what kind of instructions it can emit when generating assembly code.  This
option can be
used in conjunction with or instead of the -mcpu= option.  Permissible names
are: armv2,
armv2a, armv3, armv3m, armv4, armv4t, armv5, armv5t, armv5te, armv6, armv6j,
iwmmxt, ep9312.

OK, I'll test POVRAY.

Regards,

Denis

Post a reply to this message