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