On 14 Nov 2000 04:56:24 -0500, Warp wrote:
>Xplo Eristotle <inq### [at] unforgettablecom> wrote:
>: Here's what's bothering me, though: I have a small room with no
>: traditional lighting and a rad source (1/8th of a three foot radius
>: sphere with ambient 8 or so) in one corner, and the light it shines on
>: the far wall is decidedly splotchy, even with the nearest_count pumped
>: to 20 (the max) and the count cranked up to 600 (I really don't want to
>: go higher, as it's already slow enough, and *shouldn't* have to).
>
>  The problem is that since your bright object is small, the rays sent
>from each intersection point will hit it only rarely. This means that only
>few of these points will be illuminated by that bright object while the
>others are dark. This is what causes the splotchiness.

This made me think of something that may or may not be useful but would
certainly be an interesting idea to try (and if it works and is an 
original idea, it might be a good thesis.  Maybe I should shut up. :) )

Anyway... what if the probability of a ray being shot in a given direction 
is proportional to the brightness in that direction?

First, we need a way to determine an estimate of the amount of light 
radiated by a given cube of arbitrary size.  This can be done by tracing 
a few rays through the cube and averaging the brightness of the surfaces 
they hit, using some sort of statistical method like the one used for media 
method 1 to determine when enough we're confident in the results.

Take a cube that encloses the entire scene (this generalizes easily to a 
box.)  Use this cube as an argument to a recursive routine that does the 
following:

  Subdivide the cube into eight subcubes.
  Determine the brightness of each subcube and store the result.
  If the subcubes are smaller than a threshold, return immediately.
  If the variance in brightness over the eight subcubes is larger than a 
    threshold, call this routine for each subcube.
  
This gives you an octree of intrinsic brightness values (i.e. brightness 
resulting from ES*DL paths.)  Now you can repeat the process the routine 
below and this 1-bounce octree to determine the illumination of the 
surfaces, which will give you an octree of after-1-bounce (ES*DDL) 
brightness values that can be used to do 2-bounce radiosity.  You may now 
throw out the 1-bounce octree, because the 2-bounce version is more balanced.  
Repeat until you reach the desired recursion level or until the new octree 
looks sufficiently similar to the old one.

To determine the illumination of a surface (both while rendering and while
building new octrees) you need to fire a multitude of rays in random 
directions just as before, but with the directions weighted.  To create a
random ray, use the top-level cube of the octree as an argument to the 
following tail recursive routine:

  If there are no subcubes to the current cube, pick a random point in 
    the current cube and fire a ray at it.
  Add up the average intensities of all eight subcubes (you should be able
    to just take the average intensity of the current cube and multiply by 
    8.)  Pick a random number between zero and that sum and call it p.
  Traverse the subcubes in a predetermined order, subtracting the intensity
    of each subcube from p (and keeping the result as the new value of p.)
    When the value of p becomes negative or zero, use the current subcube 
    as the argument to this procedure, then return immediately.

If the ray returned by this procedure is behind the illuminated surface, 
keep it but give it a value of zero (if you just ignore it, you run the 
risk of getting very few qualifying rays and causing your render time to 
skyrocket.  Besides, if most of the illumination in the scene is behind
the surface, the surface won't be getting much illumination anyway.)
  
This method has three tunable parameters: the threshold at which a subcube 
is divided, the minimum size of a subcube, and the maximum number of 
recursions in the octree-building process.  The more precise these are, the
longer the octree-building process will run and the more precision will
be available in determining probability. 

There is no requirement that the recursion level of the octree-building 
process must match the recursion level of the intensity-determining 
process.  Since the octree is used only to determine the probability that
a given ray will go in a given direction, it may be very coarse indeed and
still get okay results.  The extreme case is the current case, with the 
entire octree consisting of exactly one cube of infinite size.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message