I made some more experiments in that matter, see:

Subject: Variable radiosity parameters test (~220k)
Date: Sun, 01 Sep 2002 18:42:44 +0200
From: Christoph Hormann <chr### [at] gmxde>
Newsgroups: povray.binaries.images
news://news.povray.org/3D724384.B9BF687F%40gmx.de

for the previous tests.

The new test images are on:

http://www.tu-bs.de/~y0013390/files/rad_test.html

i suggest downloading the image files and comparing them in a program able
to switch between the files quickly (like irfanview or xv) for seeing the
differences.

Concerning the different renders (all error_bound 0.4, pretrace_start 1,
pretrace_end 1/image_width, recursion_limit 2):

rad_count-120.png:
conventional fixed count 120, time ~20min

rad_count-260.png:
conventional fixed count 260, time ~45min

rad_count-260_a.png:
conventional fixed count 260, error_bound 0.1, time ~1h15min

rad_count-fn.png:
function based count, the function used is based on the object pattern,
see 'rad_object.png' for the used object, inside the object: count 260,
outside: count 120, time ~23min

rad_count-fn2.png:
function based count, additional object made of thinner cylinders and
inside count 500, minimum count 150, time ~30min

rad_count-fn3.png:
function based count, like 'fn2' but also with variable error_bound
0.4/0.1, this removes the persistent bright aretefacts but seems to have
quite strong overall (and not always positive) effects.  I'm really not
sure if varying error_bound is a good idea after all.

rad_count-adaptive.png:
adaptive count, the planned syntax of this is:

radiosity {
  ...
  count {
    MAX_COUNT, MIN_COUNT
    threshold VALUE
  }
}

The program decides whether to shoot all MAX_COUNT rays after doing
MIN_COUNT  based on the maximum and minimum distance returned by these
rays.  This seems to work fairly well, but as said before it does not
really offer much control to the user.  With the function patch enabled
too MAX_COUNT can also be a function of course.

The image uses:

    count {
      260, 120
      threshold 0.15
    }

which results in approx. 16% of the samples using 120 rays. Render time
was ~39 minutes which is much more than in the function based samples
because it improves all parts of the scene with higher count and not just
the few areas defined by the function.

rad_object.png:
The object used for the function in rad_count-fn*.png

And using functions for defining the areas of increased count is really
not that difficult, you simply have to create an object and use something
like:

#declare FnShape=
function {
  pattern {
    object { Rad_Obj }
  }
}

#declare FnRad=function(x, y, z) { select(FnShape(x, y, z)-0.5, 120, 260)
}

The render times BTW are *very* unprecise, there were other tasks running
on the machine meanwhile i did not want to stop.

Ouch, that has become quite a long post, those who have not given up
reading yet are welcome to comment. :-)

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

Christoph Hormann wrote:
> I made some more experiments in that matter, see:

  Do you like experiments, isn't? 
 
> rad_count-fn3.png:
> function based count, like 'fn2' but also with variable error_bound
> 0.4/0.1, this removes the persistent bright aretefacts but seems to have
> quite strong overall (and not always positive) effects.  I'm really not
> sure if varying error_bound is a good idea after all.
 
  Removing bright artifacts is good thing...

> rad_count-adaptive.png:
> The program decides whether to shoot all MAX_COUNT rays after doing
> MIN_COUNT  based on the maximum and minimum distance returned by these
> rays.  This seems to work fairly well, but as said before it does not
> really offer much control to the user.  With the function patch enabled
> too MAX_COUNT can also be a function of course.

  I was thinking yesterday about your adaptive-count experiment, and was 
wondering how it will decide to shoot more rays.  Distance, of course! I 
figured then it would be nice to have also adaptive error_bound and 
nearest_count. Makes it sense to have all them adaptive at the same time? 
It's possible? (Indeed, excuse my total ignorance about radiosity 
implementation....)

> Ouch, that has become quite a long post, those who have not given up
> reading yet are welcome to comment. :-)
 
  And if I just scrolled to bottom? :)

-- 
Jaime Vives Piqueres

La Persistencia de la Ignorancia
http://www.ignorancia.org

Post a reply to this message

Jaime Vives Piqueres wrote:
> 
> [...]
> 
>   I was thinking yesterday about your adaptive-count experiment, and was
> wondering how it will decide to shoot more rays.  Distance, of course! I
> figured then it would be nice to have also adaptive error_bound and
> nearest_count. Makes it sense to have all them adaptive at the same time?
> It's possible? (Indeed, excuse my total ignorance about radiosity
> implementation....)

nearest_count and error_bound are something completely different, while
count is used when gathering new samples these are relevant when old
samples are reused.  

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

"Jaime Vives Piqueres" <jai### [at] ignoranciaorg> wrote...
>   I was thinking yesterday about your adaptive-count experiment, and was
> wondering how it will decide to shoot more rays.  Distance, of course! I
> figured then it would be nice to have also adaptive error_bound and
> nearest_count. Makes it sense to have all them adaptive at the same time?
> It's possible? (Indeed, excuse my total ignorance about radiosity
> implementation....)

nearest_count could be adaptive.  However, error_bound cannot be adaptive.
As far as I can tell, error_bound is used during the creation and searching
of the radiosity octree, so it must remain constant (same value should be
used for search as for creation).

-Nathan

Post a reply to this message

Nathan Kopp wrote:
> 
> nearest_count could be adaptive.  However, error_bound cannot be adaptive.
> As far as I can tell, error_bound is used during the creation and searching
> of the radiosity octree, so it must remain constant (same value should be
> used for search as for creation).

'rad_count-fn3.png' does modify the error_bound value but it certainly has
some unpredictable side effects but it does not seem to be totally
useless, the bright artefacts at the back wall are gone and it renders
relatively fast (i did not give a time, but it was somewhere between 20
and 25 minutes).

But note the distinction between variable and adaptive parameters in this
case.  The function based method only uses the coordinates of the current
evaluation point while for the adaptive count the geometric context is
considered as well.  This won't be possible with either nearest_count or
error_bound.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message