On 05.07.2025 14:45, The Entomologist wrote:
> GREAT QUESTIONS, DENIS!

You do realise that you are responding to a message that is more than 12 
years old?

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

This is pure nonsense: You can compile each component separately. In 
fact, you can of course compile each source file separately. One could 
not put the components in libraries if this wasn't the case. So I 
suspect a user error on your part.

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

This is wrong. The parser is part of the backend.

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

No, you just have to be able to read source code and its (lengthy) 
comments. The software is open source, so there is no secret! - And as 
Ingo showed in another thread recently, even an AI can figure it out 
from the source code with surprising ease, see 
<web.6814726d2757792417bac71e8ffb8ce3@news.povray.org>

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

Your answer is wrong. You can run multiple parsers in the same process 
as well. The parser is single-threaded, that is the only difference 
compared to the render threads.

> I honestly don't think you meant parallel 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.

This is one of the easiest pieces of code to understand in POV-Ray...

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

What are you trying to say? Just because you cannot figure it out 
doesn't mean it does not work: Given you can see the image (or the file 
containing it) in the end, don't you think what you are saying implies 
more a lack of understanding on your part? The implication "Sometimes it 
works. Sometimes it doesn't." makes zero sense?!?!?

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

Well, does it occur to you that "open source" does not mean "open time"? 
If someone cannot understand the source code, they have to become 
sufficiently proficient in the programming language first. If they want 
to learn it, they have to put in the effort. Learning takes effort.

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

*plonk*

Post a reply to this message