Am 24.07.2016 um 20:41 schrieb LanuHum:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 24.07.2016 um 19:31 schrieb LanuHum:
>>>
>>> I started to learn programming language C ++.
>>> To transfer data from Blender in Povray, we use files
>>> My idea: to give up files.
>>>
>>> How will it work?
>>
>> Uh... I understand very little of what that piece of code is supposed to
>> do, most probably because of all the "PyWhatever" functions which, I
>> presume, are an interface to Python. So what you've written there is
>> probaly a wild mix of C++ and Python in C++-disguise.
> 
> You do not need to understand it. I figure it out.

"Believe me, I know what I'm doing"... now that's something that tends
to make me suspicious. I prefer to have at least some /basic/
understanding of what's going on.

(Also, if you figure it out, why do you need any help? ;))

> This is just an example of a model

That is a "scene file"? You intend to use C++ as a scene language?

Well, you'd need a C++ compiler to render a scene then. I doubt whether
that would be portable enough -- or even provide a reasonable speed
improvement over a parsed scene; after all, you'll replace a parser for
a comparatively simple domain-specific language with a parser for a
mind-bogglingly complex generic-purpose language.

Also, that would still not get you rid of files, since instead of
generating SDL files you'd then have to generate C++ files.

Unless -- and I suspect that's actually the case -- I'm completely
misunderstanding you.

>> This is currently not possible, because files are the one and only way
>> to transmit the necessary data into POV-Ray (in the form of INI and SDL
>> files, as well as image map files and the like) and back out of it (in
>> the form of image files).
> 
> Oh, that's interesting. Why is it impossible? There is no Povray scene?
> scene = new scene  NO?
> And where the parser loads the data?
> Povray causes parser. The parser is doing what?
> You can prevent the call of the parser, and cause my code.
> My code does the work of the parser.
> What is the problem?
> It is only necessary to correct code PovRay:
> if filepov:
> bla-bla-bla
> if fileblend:
> bla-bla-bla

That's how it /should/ work (and even just a naive picture thereof).

But parsing is only one part of the job -- you also need to start up and
manage the render threads, and control the assembly of their results
into an image. Not to mention photon shooting tasks, radiosity pretrace
tasks, and some such.

And the code performing that particular functionality (called the
"back-end"(*)) is still not well delineated from the render engine (aka
the "core"), the parser, and the user-defined function execution engine
(aka the "virtual machine", or "vm" for short).

It is even still interwoven with the user interface (aka the
"front-end"), or more precisely one particular piece thereof (known as
the "virtual front-end" or "vfe"); I like to consider that piece of code
my arch-nemesis in the quest for modularizing POV-Ray.

(*In POV-Ray 3.7.0, the delineation between back-end, parser, core and
vm was even worse than that, and the term "back-end" referred to the
entirety of all those modules.)

Post a reply to this message