Hello everyone,
I want to ask How we can open the source code of program POVRay?
If we can do it, we can see the flow proses rendering in POVRay and we can
modify that such we can add some coding (like MPI maybe) for get paralel
rendering program with POVRay.
Sorry, I am new in POVRay.

Regards,
Galih Pribadi

Post a reply to this message

Le 28/05/2014 02:54, gaprie nous fit lire :
> Hello everyone,
> I want to ask How we can open the source code of program POVRay?
> If we can do it, we can see the flow proses rendering in POVRay and we can
> modify that such we can add some coding (like MPI maybe) for get paralel
> rendering program with POVRay.
> Sorry, I am new in POVRay.
> 
> Regards,
> Galih Pribadi
> 

Parallel rendering on multiple cores is already supported (appeared with
3.7).

The license for version 3.7 is AGPLv3. Notice that the license for
previous versions were different.

The main problem for rendering on multiple hosts is sharing the memory
of the parsed scene (and its radiosity/photons data if any).

You can obviously fork from the git repository
 https://github.com/POV-Ray/povray

Many people already did it.

About the branches: 3.7-stable is the slowest one, equivalent to
released version. master is more reactive.
(there is two other branches, but you might stay away from them)

Post a reply to this message

Am 28.05.2014 11:00, schrieb Le_Forgeron:
> Le 28/05/2014 02:54, gaprie nous fit lire :
>> Hello everyone,
>> I want to ask How we can open the source code of program POVRay?
>> If we can do it, we can see the flow proses rendering in POVRay and we can
>> modify that such we can add some coding (like MPI maybe) for get paralel
>> rendering program with POVRay.
>> Sorry, I am new in POVRay.
>>
>> Regards,
>> Galih Pribadi
>>
>
> Parallel rendering on multiple cores is already supported (appeared with
> 3.7).
>
> The license for version 3.7 is AGPLv3. Notice that the license for
> previous versions were different.
>
> The main problem for rendering on multiple hosts is sharing the memory
> of the parsed scene (and its radiosity/photons data if any).

Photons isn't that much of a problem, since photon shooting can easily 
be parallelized; you'd just need to distribute the results before the 
main render begins.

Radiosity is a good deal trickier, as the original algorithm 
theoretically requires fully sequential operation.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

>
> Radiosity is a good deal trickier, as the original algorithm
> theoretically requires fully sequential operation.

How did you get around that? Whenever I render a scene with radiosity, all cores
are at 100% when calculating the radiosity data.

Post a reply to this message

Am 30.05.2014 02:46, schrieb jhu:
> clipka <ano### [at] anonymousorg> wrote:
>
>>
>> Radiosity is a good deal trickier, as the original algorithm
>> theoretically requires fully sequential operation.
>
> How did you get around that? Whenever I render a scene with radiosity, all cores
> are at 100% when calculating the radiosity data.

The problem is not in getting all cores busy, nor in the quality of the 
results. The main challenge in radiosity is avoiding to do redundant 
work - computing more radiosity samples than actually needed.

In a shared-memory system (such as your multi-core machine), it's not 
really that bad: Any newly calculated sample is immediately made known 
to all threads, so double work is only done if two threads happen to be 
computing samples at roughly the same spot at the same time.

In a distributed-memory system however, there is a much longer delay 
between a radiosity sample being finished and all the other processes 
learning about it, so the risk of double work goes up - especially if 
you want to prevent the network from being cluttered up by a torrent of 
short messages, and send around finished samples in bigger packages.

Obviously the whole thing also won't scale very well, as each node must 
keep each other node informed of their results.

Therefore, an entirely different approach is needed for the pretrace 
phase, where render nodes don't need to know the whole picture to do 
their part of the job.

Post a reply to this message