Everyone who has played with POV's radiosity knows that there's a
tradeoff between accuracy and smoothness. Lower error_bound and you
get splotches. Raise it, and you lose detail.

I think I have a solution. My problem is, I do not have the CPU time
and resources to test it properly.

Basically it all comes down to tricking POV into gathering more
samples in areas where one wants them. Since one has no direct
per-object or per-area control over radiosity, what we need is a trick
to introduce such controlled sampling.

Fortunately, POV provides the means for such a trick. It's save_file
and load_file together with the simple format of the radiosity data
files.

The latter are plain ASCII files which contain a dump of the radiosity
samples data. In effect, what this means is that one can concatenate
two or more such files into one and thus use the radiosity data from
all the files. If all input files are generated from the same scene
but using different camera, and possibly radiosity, settings, then the
data in the resulting file will make sense.

So, briefly, the idea is to render the scene several times using such
viewpoints and radiosity settings as to have greater control over the
sampling distribution, and using save_file to store the data. Then,
for the final trace, all data files are concatenated into one, and
load_file is used to get all radiosity data into the scene.

For example, consider a room with a chair and an apple on that chair,
using a pure rad area light source. Lighting detail will have a great
range in such a scene and will require very precise tuning of the
parameters. If one wants an accurate shadow on the apple, high quality
settings are needed, which would greatly slow down the whole scene and
will almost certainly produce blotchy results in the corner of the
room.

If, instead, one renders the scene with a camera looking at the shadow
of the apple, at close range, then there will be a lot of samples in
that area. One would then load the data into the original scene and
use such sampling settings as necessary. My guess is that much lower
settings will be enough because the bottleneck at the apple's shadow
will have been taken care of.

One may render another scene with a, say, spherical camera under the
chair, to gather as much samples in that area as possible. Then one
would merge that file with the apple shadow file and load the result
in the final scene.

The greatest benefit of this trick is that when rendering alternative
viewpoints, low radiosity settings will be used, because the sample
density only needs to be high in the final scene, and this depends on
the viewpoint. For example, with the camera at the apple's shadow, the
apple will occupy half the screen, but at the final scene it will only
take, say, 2% of the screen area. This means that for identical
results, 25 times less samples will be needed. Anything higher will
result in better sample gathering than at the original scene. So if
'count 300 error_bound 0.5' was used in the original scene, 'count 50
error_bound 1' will be a reasonable setting for an alternative
viewpoint scene. Also, the image resolution does not necessarily have
to be high, 320x240 should suffice, IMHO.

All that said, any takers? I hope this can help, especially with the
currently going rad contest in p.b.i. :)


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Peter Popov <pet### [at] vipbg> wrote:
: Everyone who has played with POV's radiosity knows that there's a
: tradeoff between accuracy and smoothness. Lower error_bound and you
: get splotches. Raise it, and you lose detail.

  I'm quite sure that the splotches are caused by some bug, which should be
possible to fix. However, if it is a bug, it's pretty elusive, and I don't
have the slightest idea what and where it could be.

: Basically it all comes down to tricking POV into gathering more
: samples in areas where one wants them. Since one has no direct
: per-object or per-area control over radiosity, what we need is a trick
: to introduce such controlled sampling.

  My own tests show that making the autocomputed distance_maximum smaller
makes povray calculate more samples where needed and it really increases
the quality of the lighting and reduces splotchiness. The render time
increases, of course, but the result gets better (you can actually get
rid of the splotchiness, not just change its frequency, as usually happens
when lowering error_bound).
  However, this is just a preliminary result, and I should test more. I have
yet to find a really good example where this can be clearly seen.

  Note that this does not fix the problem, but can greatly lessen its
symptoms. Lowering distance_maximum does not remove the splotchiness, just
reduces it drastically. (I have the feeling that if it really is a bug,
fixing it would get rid of the blotchiness without the need of calculating
more samples, so this would just be a workaround, not a fix.)

  Currently you can reduce the autocomputed distance_maximum only by
modifying the source code, so don't get too excited yet.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

On 15 Dec 2001 04:52:32 -0500, Warp <war### [at] tagpovrayorg> wrote:

>  Currently you can reduce the autocomputed distance_maximum only by
>modifying the source code, so don't get too excited yet.

So what, I have it :)

What I had in mind, though, was a trick to avoid splotchiness (by
using low settings) and still get high accuracy when needed (by
gathering samples where you want them). Care to play with it? After
all, vacation = no work :))


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Peter Popov wrote:
> 
> [...]
> 
> Basically it all comes down to tricking POV into gathering more
> samples in areas where one wants them. Since one has no direct
> per-object or per-area control over radiosity, what we need is a trick
> to introduce such controlled sampling.
> 
> Fortunately, POV provides the means for such a trick. It's save_file
> and load_file together with the simple format of the radiosity data
> files.
> 

Another possibility would be to allow variable radiosity settings
somehow.  The different values could be steered by a user defined
function, maybe similar to a texture:

#declare Rad_1=radiosity { ... }
#declare Rad_2=radiosity { ... }

global_settings {
  radiosity {
    function { ... }
    radiosity_map {
      [0 Rad_1]
      [1 Rad_2]
    }
  }
}

Of course fixing a possible bug (like Warp mentioned) is more important
than implementing such a method but anyway this could be very useful.  

Another variation of this 'variable radiosity' thought would be to
automatically calculate radiosity more precisely in shadows than in
directly lit areas.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message