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