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.

>
> 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.

Sorry! I realised just after describing the process that that probably was
how Povray operates. I then went back and tried to make the original text
make sense to a new question I wanted to ask. What I meant to say was
"Here's a really slow system. If this isn't how really really slow POV does
it, shouldn't we use this?" After that, my second method was a second
optimisation that I thought of while I was typing, so I wrote about that as
well. Sorry for the confusion.

>
> 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.

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 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.

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

> 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.

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.

Equiprawn

Post a reply to this message