"nemesis" <nam### [at] gmailcom> wrote:
> It seems to me faster results are dependent on parallelization of the
> "radiosity" calculation step and such step is being hampered of achieving such
> parallelism exactly by not being able to know in advance how much each thread
> should allow to "be visible".  At least in the case of different instances of
> povray rendering chunks of a larger image... as was the old approach to
> parallelism.  Not sure threads would improve the situation here, possibly yes,
> by having shared datastructures.

They *do* improve the situation. If I showed you a shot of what my current code
outputs, you couldn't tell it was shot in parallel - and it doesn't take
significantly more CPU time than a single thread working all on its own. CPU
time, mind you - not real time.

> OTOH, I'm aware of the locking issues...

What locking issues? There are no locking issues :) They're all sorted out.
Actually haven't been there in beta.29 at all (although the POV team hadn't
found the time yet to verify that), except for a tiny bit of more speed I was
able to gain.

> In the current implementation, second and later calculations are not stored,
> they just load the original calculations and calculate whatever is needed anew
> without ever adding up and storing to the original radiosity file.  Even if
> your 3rd frame of animation would benefit from them...

Heh - you ever tried? I must confess I didn't myself, but from what I see in the
code, using both "load_file" and "save_file" in the radiosity block should do
the trick. specifying "save_file" just causes the whole radiosity tree to be
dumped to file after rendering a frame, and doesn't care whether the samples
were loaded from file already or added during this frame.

(Unfortunately the current beta can't load/save right now)

Post a reply to this message