On Thu, 1 Jul 1999 20:56:11 +0100, Equiprawn wrote:
>Hi,
>
>>
>> It could be drawn, but I think it'd be meaningless unless both rays hit
>all
>> the same objects on the way there.
>>
>
>Why would it be meaningless? One ray might hit the red plane at a certain
>angle, and bounce direct to the field. Another might hit off the red, bounce
>straight to the blue and ano to the field. With more rays shot, a
>comprehensive radiosity map could be drawn.

My point was, the transition between those two rays is not linear.  It's 
probably more like a step function.  So blindly interpolating between them
yields suboptimal results.

>This is what I was talking about optimising. Instead of firing off random
>rays, why doesn't it shoot of rays at the objects? Surely a large portion of
>the random rays would be wasted on useless samples?

In a large scene, it may be more work to build a map of which objects are 
visible in which directions than it is to just fire a few dozen misses.

>Small or faraway objects won't contribute much, because they won't be 
>hit by many sample rays.

>Yes, but are any rays at all still calculated for them? To me, any saving of
>time, no matter how small, is a benefit.

Yes, but only in proportion to how large they appear to the object being
illuminated (and to a probability density that favors light coming in along
the normal)  The result is that the importance of small or faraway objects
is scaled automatically: they contribute little to the light striking an
object in the foreground, but they contribute more to the light striking
an object closer to themselves.  That is how it is in nature, after all.

>Ahh, I wasn't 100% sure of what the feature did (never used it myself). But
>seeing as it gives output to script writers, I would imagine it would be
>more useful than Povray's internal intersection tests for tracing.

I'm not sure I understand this.  The global illumination algorithm you're
proposing would have to be implemented in C to be of any practical use.  In
that case, you would use the intersection tests that already existed in the
official version.  All trace() is is a parser hack that's wrapped around
the existing intersection() call in the POV code.

Post a reply to this message