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 postes a message on a different section, but I think that it could be posted
here as well.



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

Am 20.12.2012 10:50, schrieb denis.beurive:

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

As a matter of fact, there is no such thing as "the" POV-Ray user 
interface; there is a GUI for Windows, and there's a command-line 
interface for Linux. (You can also start a POV-Ray render from a Windows 
command prompt, but it's a bit messy because it always starts the GUI, 
and/or delegates the render to an already running instance of it.)

>  From my point of view, there is no reason to maintain the Povray's user
> interface.

It is maintained as a convenience for Windows users: While good code 
editors are part of every Linux distro, Windows doesn't come with one 
out of the box.

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

Perfectly true.

> We could see the renderer as a compiler.

It is already seen as such.


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

Yes, that is indeed the case.

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

The collateral damage of this would be a fragmented user community: Some 
would use Perl, some Python, etc.; and it would be impossible to 
exchange parts of scenes between those factions.

It would also leave new users to the question, which language to use, 
and require them to install a 3rd-party tool (the compiler or 
interpreter for that language).

The only way around this is retaining /one/ inbuilt language as /the/ 
standard language for POV-Ray scene descriptions.


Furthermore, creating a scene is still primarily descriptive work, while 
all of the mainstream languages are imperative in nature, making them 
comparatively cumbersome for the job.


I'm therefore convinced that the proper thing to do is a thorough 
overhaul (or even redesign) of the SDL.

Post a reply to this message

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

For most Windows users I suspect setting up Eclipse is not something 
they particularly want to do. In the past I've been forced to use it for 
Java stuff and it totally sucks compared to eg the Visual Studio IDE. If 
anything the POV editor should be improved and upgraded with things like 
context-sensitive auto-complete, inline help etc. I know Mike Raiford 
was working on a POV editor based on the Visual Studio shell and it 
looked very promising.

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

You can write SDL files from your own code in whatever language you 
want. This is pretty common when generating complex scenes based on 
simulations etc.

Post a reply to this message