clipka <ano### [at] anonymousorg> wrote:
> Am 03.06.2014 11:39, schrieb gaprie:
>
> > Thanks 'Mr.clipka' for your help.
>
> That would actually be "Mr. Lipka" ;-)
>
> > which file have task to throwing the variable value (Start_Row, End_Row, Widht,
> > Height, etc) to the file view.cpp (to be evaluated in view.cpp file).
>
> That would be base/processoptions.cpp; the methods
> ProcessOptions::Parse_INI_Option() and ProcessOptions::Parse_CL_Option()
> might be good places to start.
>
> Those portions of the code actually don't really care about individual
> parameters such as Start_Row, End_Row, Widht, Height, etc; instead,
> they're just doing their job according to the tables
> RenderOptions_INI_Table[] and RenderOptions_Cmd_Table[], respectively,
> which specify what parameters actually exist, what their INI and
> command-line option names are, and what type of parameters they expect.


OK, Thanks for your Help 'Mr. Lipka'
I tried to define a variable which have value Start_Row. I define variable
'kPOVAttrib_Top =50' and 'kPOVAttrib_Bottom=200' (in file source / backend /
view.cpp) but after I build the POVRay, it be error. In the file source / base /
processoptions.cpp,  I could not find where the variable that contains the value
(as Start_Row) which I can modif.

In my purpose, I wanted to try it to find where a variable that can be modified.
If I can find it, I got the idea to add a bit of coding MPI.
So, when the POVRay program run, it POVRay will detect the number of existing
computers. If the computer detects as master, POVRay will perform the rendering
of lines until a specific line (appropriate my modification).
Can roughly like that?

Thanks for your Help.
Regards,
Galih

Post a reply to this message

Am 04.06.2014 02:03, schrieb gaprie:

> I tried to define a variable which have value Start_Row. I define variable
> 'kPOVAttrib_Top =50' and 'kPOVAttrib_Bottom=200' (in file source / backend /
> view.cpp) but after I build the POVRay, it be error. In the file source / base /
> processoptions.cpp,  I could not find where the variable that contains the value
> (as Start_Row) which I can modif.

Heh - now that would be too easy, wound't it? :-P

Unfortunately I'm not too deep into the whole POVMS stuff myself, so I 
have to learn myself while I guide you through this.

The processoptions stuff is ultimately called by the vfeSession, so we 
need to reproduce what that does; let's look at vfeSession::SetOptions() 
in vfe/vfecontrol.cpp:

- First, it creates a new POVMSObject using the POVMSObject_New 
function; this will be a message sent to the render engine. The 
kPOVObjectClass_RenderOptions enum value is a kind of message type 
identifier.

- Next, it attaches a parameters to this message, using 
POVMSUtil_SetInt(); the parameter is identified by the enum value 
kPOVAttrib_MaxRenderThreads as the maximum number of threads to use. 
(This is a machine-specific default, and may later be overridden by INI 
or command-line options.)

- Next, it loops over all INI files, and calls 
vfeProcessRenderOptions::ParseFile() for each of them. This is an 
inherited method, and is actually ProcessOptions::ParseFile(). If we dig 
through that method and its call hierarchy, we'll find out that it also 
ultmately calls POVMSUtil_SetInt(), or one of its siblings: 
POVMSUtil_SetFloat(), POVMSUtil_SetBool(), POVMSUtil_SetString(), or 
POVMSUtil_SetUTF8String().

- What vfeSession::SetOptions() then does is mainly calling 
POVMSUtil_GetXXX() functions; this way, it retrieves the parameters just 
attached by ProcessOptions::ParseFile() from the yet-unsent message.

- Another step performed by vfeSession::SetOptions() might be easily 
overlooked:

     POVMS_Object ropts (obj) ;

Note that while obj is of type POVMSObject, ropts is of type 
POVMS_Object. Fun, huh? :-P What that class does is... well, I actually 
have no clear idea :) But browsing through povmscpp.h, in which that 
type is defined, we find that its parent class POVMS_Container has some 
friend functions called POVMS_SendMessage(), so it is apparently tied to 
the actual sending of the message.


And this is where I quit the hunt for now, and leave it up to you to 
e.g. dig up where POVMS_SendMessage() is actually called and how it is 
employed :)

Post a reply to this message

> - Another step performed by vfeSession::SetOptions() might be easily
> overlooked:
>
>      POVMS_Object ropts (obj) ;
>
> Note that while obj is of type POVMSObject, ropts is of type
> POVMS_Object. Fun, huh? :-P What that class does is... well, I actually
> have no clear idea :) But browsing through povmscpp.h, in which that
> type is defined, we find that its parent class POVMS_Container has some
> friend functions called POVMS_SendMessage(), so it is apparently tied to
> the actual sending of the message.

You do not need it to send a message! The C++ class is nothing more than a
wrapper around the C functions of POVMS. You can send messages with the C API
directly.

Or you can mix the C and C++ APIs pretty much as much as you want - like the
quoted code does. The history behind it is trivial: The C++ API was written
years after the C API, so there was lots of C API code around and no need to
convert it to C++.

For a beginner, I would recommend using the POVMS C++ API exclusively because it
greatly reduces the risk of memory leaks and pointer errors.

Post a reply to this message

Am 04.06.2014 23:27, schrieb Thorsten Froehlich:
>> - Another step performed by vfeSession::SetOptions() might be easily
>> overlooked:
>>
>>       POVMS_Object ropts (obj) ;
>>
>> Note that while obj is of type POVMSObject, ropts is of type
>> POVMS_Object. Fun, huh? :-P What that class does is... well, I actually
>> have no clear idea :) But browsing through povmscpp.h, in which that
>> type is defined, we find that its parent class POVMS_Container has some
>> friend functions called POVMS_SendMessage(), so it is apparently tied to
>> the actual sending of the message.
>
> You do not need it to send a message! The C++ class is nothing more than a
> wrapper around the C functions of POVMS. You can send messages with the C API
> directly.
>
> Or you can mix the C and C++ APIs pretty much as much as you want - like the
> quoted code does. The history behind it is trivial: The C++ API was written
> years after the C API, so there was lots of C API code around and no need to
> convert it to C++.
>
> For a beginner, I would recommend using the POVMS C++ API exclusively because it
> greatly reduces the risk of memory leaks and pointer errors.

Thanks for the clarification.
You don't happen to have any documentation for it, do you?

Post a reply to this message

Am 04.06.2014 23:27, schrieb Thorsten Froehlich:

> You do not need it to send a message! The C++ class is nothing more than a
> wrapper around the C functions of POVMS. You can send messages with the C API
> directly.

(That, by the way, explains why when digging around the POVMS code I 
always had the impression that it had one or two layers more than 
necessary.)

Post a reply to this message

Thanks for Mr.Lipka and Mr.Thorsten Froehlich for help.

I'm confused, I tried hard to understand and some hints from you guys.

so far I find the variable in the "source / backend.scene / view.cpp" ie "DBL
ratop" and "DBL rabottom". I try to change the value in the variable becomes
"DBL ratop = 1" and "DBL rabottom = 200" that, through my Povray build and run
the command "Povray pawns.pov" produces an image that has been rendered
pawns.png up to 200 lines.

I actually wanted to find a file whose job is to read the commad line
(ex: "Povray +SR1 +ER200 +Ipawns.pov ER200") and threw it into the main Povray
rendering process.

If the file is written in C, then I want to add a bit of coding MPI:

MPI_Comm_size (MPI_COMM_WORLD, &sum_of_nodes);
MPI_Comm_rank (MPI_COMM_WORLD, &number_of_node);

if (number_of_node == 0) {
  ......

 .....
}
else {// number of nodes = 2
 ......

 ......
}

So I expect every POVRay application that has been added a bit coding MPI will
build on each nodes.
Each nodes will do his job, for example, the first nodes do his job (line -100)
and the second node working line 101-200.

Is my explanation understandable?
Sorry I am still new in Povray.

Thanks for help.
Regards,
Galih Pribadi

Post a reply to this message

Am 05.06.2014 19:17, schrieb gaprie:

> I actually wanted to find a file whose job is to read the commad line
> (ex: "Povray +SR1 +ER200 +Ipawns.pov ER200") and threw it into the main Povray
> rendering process.

There is no such file, because POV-Ray /already/ uses some MPI-ish 
interface between the part we call the front-end and the part we call 
the back-end (with the design goal to ultimately support multi-node 
operation in some future version).

The front-end is a single thread responsible for reading the command 
line, and later assembling and writing the output image.

The back-end is actually multiple threads: One parser thread responsible 
for parsing the scene file (in a multi-node environment there would have 
to be one such thread per node), and a number of threads rendering the 
image in chunks of 32x32 pixels at a time. A thread finished with its 
chunk would send the results to the front-end, then go for the next 
yet-unrendered chunk.

The interface used for message passing does not conform to the MPI 
standard defined by the Argonne National Laboratory, but uses a 
proprietary API: The thing called POVMS, which - as Thorsten has already 
noted - comes in both a C and a C++ version (the latter being 
implemented as a wrapper around the C API).


If your goal is not to just throw together a quick hack to run POV-Ray 
on multiple nodes, but to create some decent solution that future 
development can build on, maybe you should actually work on the POVMS 
implementation itself to get it flying across node boundaries. (Or, as a 
potential alternative, rip out POVMS entirely and replace it with some 
widespread and well-maintained MPI library.)

If your goal /is/ to just throw together a quick hack, then maybe you'd 
actually be better of with some shell scripts that just run multiple 
POV-Ray instances with suitable parameters, followed up with some 
imagemagick call to paste the results together.

Post a reply to this message

Le 05/06/2014 19:17, gaprie nous fit lire :
> I actually wanted to find a file whose job is to read the commad line
> (ex: "Povray +SR1 +ER200 +Ipawns.pov ER200") and threw it into the main Povray
> rendering process.

source/base/processoptions.cpp

but you might need to look also at the vfe (virtual front end),
implemented for your system (unix, windows ...), that's where main() is.

The vfe/ hierarchy is complex on its own. (their is a subpart for unix,
and another for windows)

Parsing options fills the memory... and later, getters are provided with
default if the memory is not filled for a property.
Properties are encoded on a 4 bytes id, that's the part VMS transfers
around. You will find them in source/backend/povmsgid.h :-)



-- 
IQ of crossposters with FU: 100 / (number of groups)
IQ of crossposters without FU: 100 / (1 + number of groups)
IQ of multiposters: 100 / ( (number of groups) * (number of groups))

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 05/06/2014 19:17, gaprie nous fit lire :
> > I actually wanted to find a file whose job is to read the commad line
> > (ex: "Povray +SR1 +ER200 +Ipawns.pov ER200") and threw it into the main Povray
> > rendering process.
>
> source/base/processoptions.cpp
>
> but you might need to look also at the vfe (virtual front end),
> implemented for your system (unix, windows ...), that's where main() is.
>
> The vfe/ hierarchy is complex on its own. (their is a subpart for unix,
> and another for windows)
>
> Parsing options fills the memory... and later, getters are provided with
> default if the memory is not filled for a property.
> Properties are encoded on a 4 bytes id, that's the part VMS transfers
> around. You will find them in source/backend/povmsgid.h :-)

My branch in Perforce still contains a modified late 3.7 beta that has POVMS
properly separating frontend and backend to work in independent processes. It is
a much better start for an MPI version because it has many dependencies cleaned
up and the POVMS that comes with it can handle "addresses" of various kinds.
Ranging from pipes to TCP/IP ports. Extending it with MPI addresses should be
fairly little work. I will see if I can zip up a version that compiles one day.
No promises when that will be though...

Thorsten

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> The interface used for message passing does not conform to the MPI
> standard defined by the Argonne National Laboratory, but uses a
> proprietary API: The thing called POVMS, which - as Thorsten has already
> noted - comes in both a C and a C++ version (the latter being
> implemented as a wrapper around the C API).
>
> If your goal is not to just throw together a quick hack to run POV-Ray
> on multiple nodes, but to create some decent solution that future
> development can build on, maybe you should actually work on the POVMS
> implementation itself to get it flying across node boundaries. (Or, as a
> potential alternative, rip out POVMS entirely and replace it with some
> widespread and well-maintained MPI library.)

One reason to create POVMS was that MPI at the time (1997/1998) was not really
good at handling multiple threads (especially cooperative threading like Macs
had at the time) and implementations existed mostly for Unix, yet multithreading
is a huge benefit for ray-tracing. Seems like this has not changed a lot since
then, i.e.
http://www.open-mpi.org/~jsquyres/www.open-mpi.org/doc/v1.8/man3/MPI_Init_thread.3.php
still says it is no good for heavily multithreaded applications :-( So
effectively one would need to have a three layer communication instead of a two
layer communication in POV 3.7 to use MPI: MPI processes of POV with a central
server process controlling rendering and collecting results - POV processes each
with single MPI communication thread that bundles local POVMS messages - POV
threads that use POVMS for in-process communication.

As for POVMS message data exchange, it will work by simply putting POVMS message
streams into MPI byte arrays. POVMS streams already handle byte ordering, float
type conversion etc., so it should be straight forward.

Post a reply to this message