stochastic algorithm query?
Ray Bellis
The intention was to experiment with stochastic techniques for things like
area lights, etc. The deterministic version works fine, but for the
stochastic version I can't find any decent reference material on how to
handle diffuse inter-reflection.
For the stochastic version I'm not using lights, I'm using high-ambient
solids. This means there's no explicit direct rays back to light sources,
nor shadow calculatations. I could do with guidance on whether that's a
mistake or not.
Currently I'm just spawning a few new rays in random directions and summing
those (weighted by the dot-product of the surface normal and the new ray and
divided by the number of rays) but even after many hours on a 16-core box
the results are incredibly speckly. Also the image turns out much darker
than expected, I think because so many of my random diffuse rays are just
hitting the black background.
Any pointers gratefully received...
cheers,
Ray
FeepingCreature
> For the stochastic version I'm not using lights, I'm using high-ambient
> solids. This means there's no explicit direct rays back to light sources,
> nor shadow calculatations. I could do with guidance on whether that's a
> mistake or not.
Stochastic methods work best against large surfaces, unless you're using something clever and incomprehensible like MLT.
If you want a fuzzy light source, just add a random vector to its position every trace.
> Currently I'm just spawning a few new rays in random directions and summing
> those (weighted by the dot-product of the surface normal and the new ray and
> divided by the number of rays) but even after many hours on a 16-core box
> the results are incredibly speckly. Also the image turns out much darker
> than expected, I think because so many of my random diffuse rays are just
> hitting the black background.
>
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.
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) }
As a simple test: a white(diffuse) plane under a sky with ambient color should have the same color as the sky.
(I've run into the same problem with a path tracer earlier today ^^)
Ray Bellis
> using something clever and incomprehensible like MLT.
>
> If you want a fuzzy light source, just add a random vector to its
> position every trace.
Yup, that's something like what I've concluded, although this appears to
mean that I need to treat my high-ambient "light sources" differently to
other objects.
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.
> 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.
> 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.
> As a simple test: a white(diffuse) plane under a sky with ambient
> color should have the same color as the sky.
Thanks, I'll try that too.
Ray
news.chr...@gmail.com
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