Area light sampling [Re: Experimental additions...]

[Kevin Harris]

On Sun, 1 Oct 2000 address@hidden wrote:
> > This required that every object be given a function to return a random
> > point on the surface (easier than a 2d-3d mapping), with a default
<snip>
> How is the ability to select a random point on an arbitrary surface
> useful for area lights? Wouldn't the probability distribution depend

For a simple approximation of an area light, it would allow lighting
effects.  After all, graphics is one big hack, isn't it?  From the
beginning, it's all been about approximating what really happens.

Think about Phong highlights, and how they compare to the BRDF of a
surface. The BRDF looks much more accurate, but the Phong highlights are
trivial to implement, and much faster to calculate.  This would be the
similar getting an accurate projection of an area light compared to
randomly choosing a point on its surface and shooting a ray. 

:)

> on the location and orientation of the receiving surface? Thus, one
> should really be selecting a random direction spawned from the
> receiver, possibly weighted by the BRDF and distribution of the
> incoming radiance.

If one could easily determine which portions of the surface were indeed
visible (possibly by way of the mesh for the surface and a bsp tree), it
would be possible to send rays to the near side, with the probability of
hitting any portion of the visible mesh weighted by the projected area.
That is, the area it would project onto the visible hemisphere from the
surface.  Weighting for the brdf would also help reduce the number of
samples required to get a good image.

> Consider a spherical luminaire: If one selects a uniformly random
> point over its surface from which to cast rays to a receiving surface,
> there will be a clear bias towards the silhouette edges of the
> sphere. This is true for most regularly shaped luminaires.
>
> Problems are worse for an object that can self occlude -- how does one
> measure the fraction of light reaching the receiver in that case? Does
> a very bumpy light source illuminate its environment any less than a
> smooth one of the same size and intensity?

Well... There's a simple solution here.  If you just wanted a simple
approximation, then the code that sends the shadow rays can check any
non-transparent objects which it intersects before reaching the randomly
chosen point on the surface.  If it happens to intersect with the light
source from which it is trying to sample, change the point to the
closer intersection (this is what I've done).  

As you mentioned, this does have one negative side effect, though.  Any
solid object will have bright spots, with areas of the surface being
over-sampled.  The overall effect is that the image have too much
illumination, and not less (like without the simple hack). 

The execution cost compared to a point light would be the selection of the
random point on the surface, one extra compare (after a non-transparent
object has been hit), the evaluation of its illumination at the
intersected point, and a few extra samples per pixel to get a decent
image.  In return, it offers soft shadows, variable emission, and visible
light sources.

The execution cost of an accurate method would be the traversal of some
form of space partitioning tree (ie. bsp), some number of projective area
calculations, randomly (possibly weighted) selection of a point, and the
evaluation of the illumination.  It would also involve much more code.
This may be a good thing to do in the future, but I consider it too
expensive (in terms of execution time, and programming/debugging hours)
for the current level of completeness of panorama.

Until the lighting models in panorama are rewritten, I think that an
approximation of lighting (even with bright spots) is better than
disallowing area lights altogether.  

If someone wants to spend the time to create accurate modeling of area
lights, I wouldn't complain a bit. :)

-Kevin-