"nemesis" <nam### [at] gmailcom> wrote:
> It seems this feature, while a nice optimization trick, is what prevents one
> from reusing a full saved rad file to render a file from a different angle
> without taking any more samples and probably also the root cause of not being
> able to simply break an image into sections, render them separately and simply
> merge the final renders into a single image later.  Each instance do not know
> they should be taking samples from areas not seen in their particular view.
>
> Perhaps this optimization was powerful then, but not quite as fitting in an era
> of multicore processors and parallel processing.  Would it be possible to
> simply remove this view-dependent constraints and allow for full view
> independence in the current implementation?  How bad would performance drop?

If you have a scene containing a complete 10-storey house, and you only want to
render a single room - it'll kill.

It's an extreme example, but it shows that (a) your question cannot be answered
without knowing the scene, and how much of it is actually visible, and (b)
processing power has not increased so much to just go for plain brute force.

In fact, instead of spending the processing power to speed up *potential* later
renders of other parts of the scene, I'd rather see the added power invested in
(a) more detail, (b) higher quality and (c) faster results.

Actually, in an ideal world, the view-based approach of Ward's algorithm should
still prove superior to a pre-render of the whole scene, regardless of scene
size. It would be as follows:

- First image is pretraced, producing all necessary samples for the first shot
- First image is rendered, no additional samples are needed
- Second image is pretraced, re-using what the first pretrace produced, and
adding what is missing
- Second image is rendered, no additional samples are needed
- ...

The only problems here are...
(a) that the pretraces often do *not* produce all the necessary samples for some
reason;
(b) that the settings do not produce good enough quality; so the quality
increases from shot to shot (because for some parts they have more samples
available than they would actively collect themselves), but people think the
algorithm just produces randomly different results (partly because it is not
easy to asses which picture is actually more accurate);
(c) that the pretrace step may be done wrong, if a separate render is used; for
example, if you use micronormals, it is actually a bad idea to disable them for
the pretrace, because it causes the pretrace to collect less (and insufficient)
samples; likewise, reducing the recursion depth during pretrace may cause
additional samples to be required during the main render. Probably the only
quality setting that can safely be disabled is area light resolution (though
this could cause artifacts if additional samples are required during main
render for other reasons).

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "nemesis" <nam### [at] gmailcom> wrote:
> If you have a scene containing a complete 10-storey house, and you only want to
> render a single room - it'll kill.
>
> It's an extreme example, but it shows that (a) your question cannot be answered
> without knowing the scene, and how much of it is actually visible, and (b)
> processing power has not increased so much to just go for plain brute force.

I'd never put a full building to render when only targetting a room.  It's up to
the user to render their scenes in little passes and then combine them -- or
not, in this case.  Perhaps some sort of "radiosity bounding box" could help
here?

> In fact, instead of spending the processing power to speed up *potential* later
> renders of other parts of the scene, I'd rather see the added power invested in
> (a) more detail, (b) higher quality and (c) faster results.

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.  OTOH, I'm aware of the locking issues...

> - First image is pretraced, producing all necessary samples for the first shot
> - First image is rendered, no additional samples are needed
> - Second image is pretraced, re-using what the first pretrace produced, and
> adding what is missing
> - Second image is rendered, no additional samples are needed
> - ...

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

Post a reply to this message

"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

nemesis <nam### [at] gmailcom> wrote:
> It seems this feature, while a nice optimization trick, is what prevents one
> from reusing a full saved rad file to render a file from a different angle
> without taking any more samples and probably also the root cause of not being
> able to simply break an image into sections, render them separately and simply
> merge the final renders into a single image later.  Each instance do not know
> they should be taking samples from areas not seen in their particular view.

  I don't see how viewpoint-independence would help solve the problem. The
only thing a viewpoint-independent solution would do is calculate more
samples (including many samples which do not contribute anything to the
rendered image) and that's it. It might allow re-rendering the scene with
a moved camera without having to calculate more samples, but I don't see
how it would help any of the actual problems.

  A viewpoint-independent version of the current algorithm would (most
probably) not reduce lighting artifacts, make it any easier to get
good-looking lighting without tons of tweaking, and most relevantly,
would not make it any easier to distribute the calculation of the samples
at render-time. You would still have all the problems of the current
algorithm (eg. how to make one thread see the results of another, how
to avoid two threads calculating the same sample, etc).

> Perhaps this optimization was powerful then, but not quite as fitting in an era
> of multicore processors and parallel processing.

  The global illumination algorithm used by POV-Ray was slow then, and it's
slow nowadays. Deliberately making it even slower is not the way to go.

-- 
                                                          - Warp

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "nemesis" <nam### [at] gmailcom> wrote:
> > OTOH, I'm aware of the locking issues...
>
> What locking issues? There are no locking issues :) They're all sorted out.

Hmm, but you guys had quite some fun a while back with this discussion. ;)

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

Aaaahhhhhhhhhhhhhhhh!!!

One of those magic trickery people shout about pov's rad! :P

Post a reply to this message

"nemesis" <nam### [at] gmailcom> wrote:

> Aaaahhhhhhhhhhhhhhhh!!!
>
> One of those magic trickery people shout about pov's rad! :P

So... is this an "Aaaahhhhhhhhhhhhhhhh!!! it doesn't work", or
"Aaaahhhhhhhhhhhhhhhh!!! If only I'd known that earlier" ?

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "nemesis" <nam### [at] gmailcom> wrote:
>
> > Aaaahhhhhhhhhhhhhhhh!!!
> >
> > One of those magic trickery people shout about pov's rad! :P
>
> So... is this an "Aaaahhhhhhhhhhhhhhhh!!! it doesn't work", or
> "Aaaahhhhhhhhhhhhhhhh!!! If only I'd known that earlier" ?

More of the latter, but didn't really try it.  My pov files are in my home comp
and I'm on vacation... :P

Post a reply to this message

"nemesis" <nam### [at] gmailcom> wrote:
> "clipka" <nomail@nomail> wrote:
> > "nemesis" <nam### [at] gmailcom> wrote:
> >
> > > Aaaahhhhhhhhhhhhhhhh!!!
> > >
> > > One of those magic trickery people shout about pov's rad! :P
> >
> > So... is this an "Aaaahhhhhhhhhhhhhhhh!!! it doesn't work", or
> > "Aaaahhhhhhhhhhhhhhhh!!! If only I'd known that earlier" ?
>
> More of the latter, but didn't really try it.  My pov files are in my home comp
> and I'm on vacation... :P

But did you never wonder, "what happens if I use both load AND save"?

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "nemesis" <nam### [at] gmailcom> wrote:
> > "clipka" <nomail@nomail> wrote:
> > > "nemesis" <nam### [at] gmailcom> wrote:
> > >
> > > > Aaaahhhhhhhhhhhhhhhh!!!
> > > >
> > > > One of those magic trickery people shout about pov's rad! :P
> > >
> > > So... is this an "Aaaahhhhhhhhhhhhhhhh!!! it doesn't work", or
> > > "Aaaahhhhhhhhhhhhhhhh!!! If only I'd known that earlier" ?
> >
> > More of the latter, but didn't really try it.  My pov files are in my home comp
> > and I'm on vacation... :P
>
> But did you never wonder, "what happens if I use both load AND save"?

*shame*

no... Guess sometimes RTFM just hurts more than simply messing around... :P

But do you know for sure?

Post a reply to this message

"nemesis" <nam### [at] gmailcom> wrote:
> > But did you never wonder, "what happens if I use both load AND save"?
>
> *shame*
>
> no... Guess sometimes RTFM just hurts more than simply messing around... :P
>
> But do you know for sure?

No, as I mentioned before: I didn't try it myself. I know it should work because
I've seen it in the code, but I'm too much of a real-life software developer to
trust in code until I have actually tested it :)

Post a reply to this message