Re: stochastic algorithm query?
- From: news.chris.theis@xxxxxxxxx
- Date: Fri, 17 Oct 2008 07:54:28 -0700 (PDT)
On Sep 8, 10:54 pm, "Ray Bellis" <use...@xxxxxxxxxxxxxxxx> wrote:
Hi Ray,
[SNIP]
I think I'm effectively seeing the downside of not treating lights like
lights - a real light floods the environment with photons in all directions,
but I'm relying on the chance that a back-traced ray might hit a light. The
problem is that most such rays don't.
In traditional ray tracing you perform backwards tracing in order to
deal only with those rays that will be seen by your camera and thus,
should have the most notable contribution to your image. Thus, you'll
get a picture in a fairly short amount of time but you're missing out
on the subtleties of indirect illumination. Implementing a path-
tracer, as you're doing, will yield those effects but at the cost that
a straight-forward implementation is not very efficient and usually
shows a relatively high variance.
I may be talking out of my ass here, but are you using the C standard
RNG?
It's known to have problems with visible patterns.
I'm using Java (for the multithreading). The problem I have isn't
repetitive patterns, it's speckling all over, which doesn't appear to reduce
significantly over time.
As mentioned before you will always find a rather high variance in
your images with path tracing. Even though the result will eventually
converge to the correct distribution of photons/energy in your scene,
the time required might be enormous. You can find a nice comparison of
methods on the following webpage:
http://www.dgp.toronto.edu/~jacky/raytracer.php -- look at the images
which only contain indirect illumination.
However, there are a couple of techniques that reduce the variance
while taking indirect illumination into account. The basic idea is
that you don't shoot & construct your rays with a purely random
distribution but you try to restrict yourself to those that should
yield a significant contribution to your final image.
One way is the Metropolis-Light-Transport approach which was already
mentioned before, or another way is for example bi-directional path
tracing. In this approach you will construct paths of photons from the
light source (forward tracing) and from the eye (backward tracing).
Finally one tries to connect them in a clever way and in the end you
should have a reconstruction of photon paths that will start at the
light source and end at the position of the camera.
Other solutions basically split the transport equation into two parts,
the direct and the indirect contribution. Using a number of state-of-
the-art global illumination techniques, like final gathering, photon
mapping, irradiance caching etc., the indirect illumination is
calculated for the scenery and merged with the results obtained from
traditional backward ray tracing that should yield the direct
contribution.
Also, it's better to use a cosine _sampling_ for the rays, i.e. while
true { get a ray on the halfsphere; return it if its dot with the
normal is greater than randf (0..1) }
Ah, OK, thanks - that's a useful hint.
Pure random sampling of the direction might yield more variance, so
you should consider cosine weighted sampling as suggested by one of
the previous posters. However, I'd suggest also other methods than a
rejection loop as it's not the most efficient way to obtain a cosine
weighted distribution on a hemisphere.
One way would be to calculate the two angles theta [0, pi/2] and phi
[0, 2pi] the following way:
r1 and r2 = two uniformly distributed random numbers [0,1)
Phi = 2 * pi * r1
Theta = 1/2 * acos( 1 - 2 * r2)
Another approach is Malley's method: you basically calculate a uniform
distribution of points on a 2D disk and then generate directions by
projecting them up to the hemisphere above them.
x, y = UniformPointsOnDisk();
z = sqrt( max( 0.0, 1 - x*x - y*y) );
In any case you might google for "global illumination" or check out
the book "Advanced global illumination" by Philip Dutre.
Hope that helps
Chris
.
Relevant Pages
|
