On Wed, 30 Jun 1999 15:19:00 +0100, Equiprawn wrote:
>Now imagine that our 3D light source shoots out two rays, in slightly
>different directions. They each bounce in different ways, depending on what
>surfaces they hit or miss. Eventually, they hit our final calculation field,
>which is now a rectangle. We now have two different points of two (probably)
>different colours. A stripe of interpolated colours fading between our two
>colour spots could be drawn.

It could be drawn, but I think it'd be meaningless unless both rays hit all 
the same objects on the way there.

>This is, as far as I know, more or less how
>Povray operates. If it isn't, would this not be a much better way to
>calculate radiosity? It certainly seems like it would be faster to me, for
>simple scenes anyway. If that is however how Povray calculates radiosity,
>keep reading.

Okay, so let me get this straight.  You say "Here's this really slow system.
If this isn't how POV does it, shouldn't it be?"  I'm having trouble grasping
that.

The fact is, this isn't how POV operates.  It doesn't trace any rays starting
with the light sources, for the very reasons you mention below: most of the
samples would be useless.  Instead, it fires a pile of random rays at the 
surrounding scenery whenever it needs to compute radiosity effects for a 
given intersection point, then caches the results for use with other nearby 
points. This ends up handling the most obvious cases of diffuse 
interreflection, such as indirect lighting, while ignoring cases of multiple 
bounces.  Note that there are no fixed counts for any objects, including 
lights.  POV fires an easily computed number of sample rays per intersection 
(if it needs to) but those sample rays are not associated with any one light 
source.

In this model, the number of sample rays for a specific object is highly
dependent on screen area taken up by that object.  Thus, large or close objects 
will be illuminated more carefully.  The number of times an object is the 
target of one of those sample rays is dependent on how visible that object is 
to the source of the sample rays.  Small or faraway objects won't contribute 
much, because they won't be hit by many sample rays.

What you're envisioning is roughly how photon mapping operates, though there 
are additional subtleties in both Nathan's and Jensen's implementation of it 
that are too difficult to talk about in detail here.

>if any of this would be possible. I know that Mr. Nathan Kopp was looking at
>the radiosity system when he was working on his excellent Photon Patch. I
>also know that in the Povray SuperPatch, there is a feature that allows ray
>intersection tests, a feature that would be very important in the above
>proposed radiosity system.

The superpatch feature you're thinking about is only to make the existing ray 
intersection tests available to people writing POV-script. The ray intersection 
tests were all already there, obviously, because that's what a raytracer does.

Post a reply to this message