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 ?



### 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 ?



### 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.
From my point of view, there is no reason to maintain the Povray's user
interface.

I guess that Povray does not use any OS dependant library for the rendering.

We could see the renderer as a compiler.



### 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.



Best regards,

Denis

Post a reply to this message

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'.

Post a reply to this message

Hello,

Thank you for your answer.

Yes, we can run POVRAY from the command line... but it opens the user interface
!
You have to specify /EXIT if you want to close the window when the rendering is
done...
And there is no way to specify the INI file.

I'd thought something like :

povary -s my_scene.pov -i my_inifile.ini -o my_image.jpeg -I include_path

I looked at the code.

First of all it looked very clean.

I tried to build it on my Macbook pro (Mac OS X version 10.7.5), using the GNU
compiler.
I know it would not build, but I just wanted to see how far I could go.

Correct me if I am wrong :

First of all, it seems that the following libraries could be installed using
some packaging tools (ex: for MAC, "ports") :

libraries/jpeg
libraries/png
libraries/tiff
libraries/zlib

jpeg6b @6b (graphics)
    Library for manipulating JPEG images
 port install jpeg

libpng @1.5.13 (graphics)
    Library for manipulating PNG images
 port install libpng

tiff @3.9.7 (graphics)
 Library and tools for dealing with Tag Image File Format
 port install tiff

zlib @1.2.7 (archivers)
 zlib lossless data-compression library
 port install zlib

Is their any reason to include this third part libraries in the POVRAY
distribution ?



Regarding the OS independence, I am not sure. While I compile on MAC OS X, I
have the following message :

CPU you selected does not support x86-64 instruction set

This message seems wrong, because new Apple computers uses Intel processors
(that supports 64 bits).

I did not dig further. I'd do it later.

Does POVRAY uses assembly ?



Regarding the execution speed, I have no idea if using an interpreter would
change something.
But I think, that it would not change anything :

The hard work is not the parsing of the description file. The hard work is the
rendering itself.
Writing a specific parser, or using the parser of an interpreter (such as Perl,
Python, PHP or Ruby) should not make a big difference.

Best regards,

Denis

Post a reply to this message

>
> Nabla mu.
>
> You seems to have seen povray for Windows and not the unix version which
> is reduced to a command-line interface.

Sorry, I did not understand correctly.

I'll will try under Linux.

Regards,

Denis

Post a reply to this message

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

Am 22.12.2012 14:46, schrieb denis.beurive:
> Hello,
>
> Thank you for your answer.
>
> Yes, we can run POVRAY from the command line... but it opens the user interface
> !
> You have to specify /EXIT if you want to close the window when the rendering is
> done...
> And there is no way to specify the INI file.
>
> I'd thought something like :
>
> povary -s my_scene.pov -i my_inifile.ini -o my_image.jpeg -I include_path

Try

   povray -Imy_scene.pov my_inifile.ini -Omy_image.jpeg -Iinclude_path


> I looked at the code.
>
> First of all it looked very clean.

So we're obviously talkig about POV-Ray 3.7.


> I tried to build it on my Macbook pro (Mac OS X version 10.7.5), using the GNU
> compiler.
> I know it would not build, but I just wanted to see how far I could go.

Why didn't you get the Unix source package, instead of the Windows source?


> First of all, it seems that the following libraries could be installed using
> some packaging tools (ex: for MAC, "ports") :
>
> libraries/jpeg
> libraries/png
> libraries/tiff
> libraries/zlib
>
> ...
>
> Is their any reason to include this third part libraries in the POVRAY
> distribution ?

Note that they're only included in the Windows distribution.

Yes, there's a very compelling reason: The concept of such library 
"packages" is alien to the Windows ecosystem.


> Regarding the OS independence, I am not sure. While I compile on MAC OS X, I
> have the following message :
>
> CPU you selected does not support x86-64 instruction set
>
> This message seems wrong, because new Apple computers uses Intel processors
> (that supports 64 bits).

Sounds more to me like your compiler isn't set up properly. Something 
like a combination of "please generate 64-bit code" and "target CPU is 
generic x86".


> I did not dig further. I'd do it later.
>
> Does POVRAY uses assembly ?

No.


> Regarding the execution speed, I have no idea if using an interpreter would
> change something.

As for parsing speed, POV-Ray /does/ use an interpreter (except for 
functions, which are compiled into some kind of bytecode), so it can 
only get better.

Post a reply to this message

Am 22.12.2012 15:42, schrieb denis.beurive:

> 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.

The GCC documentation contains multiple hardware-specific sections, many 
of which have their own subsection on the "-march" flag. The one you 
quoted is for the ARM architecture; in the section on Intel 386 and AMD 
x86-64 you'll find something like:

------------------------------
-march=cpu-type
Generate instructions for the machine type cpu-type. The choices for 
cpu-type
are the same as for -mtune. Moreover, specifying -march=cpu-type implies
-mtune=cpu-type.
------------------------------

Best choice in your case should be "-march=native".

Post a reply to this message

> > Would it be difficult to separate the renderer from the user interface ?
 > > ie:
 > > ### Question 1 :
 > > ### Question 2 :

GREAT QUESTIONS, DENIS!

It is possible. But, yes, it would be difficult. I've tried a number of times,
with different POV versions, the main problem being that you get a lot of errors
when you try to compile them separately.
The code is divided into two groups - front-end and back-end - which are
supposed to represent what you describe as (1) user interface + parser in the
"front" and the (2) renderer in the "back". However, the documentation for
programmers is a well kept a secret and I've found no description of the
interface between the two. You'll have to find it yourself by trial and error.

 > > 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 ?

It isn't clear what you mean by "a separate process". The renderer is
multithreaded, if that's what you are after. As soon as one scene is being
rendered, you may begin parsing the next. But you can't begin rendering before
the parser has finished parsing.

I honestly don't think you meant parallell runtime processing. But rather how to
extract the rendering code from the rest of the code files. I've had the same
issue a number of times. But I've never solved it. I was almost only interested
in meshes and triangles, so I wrote a number of POV-files to generate those and
then I traced the execution to see what back-end classes and functions were
called and how. It doesn't solve every problem. But it gave me some idea of how
a scene is built in memory before the rendering begins.
Then comes the issue of trying to figure out how and where the program gets the
complete image after rendering. Sometimes it works. Somtimes it doesn't. And if
you compile your own home made program to exe and run it, it never shows you the
image.

 > > First: English is not my mother language. I do my best to be clear.
 > > ...
 > Nabla mu.

Responding with jibberish to someone, who has made it clear english might be a
hard language to read, seems unnessessarily rude.


 > Show us that you have spent more time on the subject than it would take some
of
 > us to answer in this thread.

This is another good example of how to not respond to a serious question. The
main reason why people ask questions in general is to save time when trying to
learn something new. If you want others to appreciate and use POV-Ray or any of
its forked projects, you should try to help. That's what these forums are for.


 > I know the answer, but you are not ready for it.

Again, Le_Forgeron seems annoyd that someone wants to learn for free, what
Le_Forgeron had to learn rhe hard way. Yet another missed opportunity to show
off as one of the good guys. The above answer reads "I could explain it to you.
But I'm far too lazy".


 > De gustibus... (et coloribus non est disputandum)
 > ...
 > Don't guess, look at the code and the compilation environment.

Again and again. #:(


 > 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).

It turns out, Le_Forgeron isn't that lazy after all. He puts a lot of effort
into trolling this thread. And it goes on. But I think I've made my point. My
apologies to Denis Beurive on behalf of the POV-Ray community for the abusive
responses he had to suffer here. I am amazed he didn't leave for good, but he
ignored the harsh tone and persisted in his inquiry.

To the rest of us, who always think we are better than the rest: Try to behave
and do good. We are all here to help and get helped whenever possible. Some of
us are beginners, others have been around for decades. Some, like Denis, wonder
if the source code is worth even to begin working with.

Post a reply to this message