Thorsten Froehlich <tho### [at] trfde> wrote:
> I disagree. Trace is the algorithm, and as such it controls recursion. A ray
> does neither, and all you end up with is an uncontrollable recursion
> counter. As the recursion limit is a property of trace, there is no way a
> ray could enforce the limit. So what do you gain by adding the recursion
> level to a ray? - Nothing. What feature gets lost? - The ability to control
> the recursion limit. -- And that you do not want!!!

I don't lose anything, because the algorithm can always query the information on
the current trace depth.

> The real issue is different, and I can understand you confusion: The
> lighting code has a problem with division of work, in 3.7 it is just
> slightly better than in previous versions of POV-Ray. Once there is (4.0) a
> clear separation of the tracing and the lighting computations (and those of
> textures), it will be very clear that there are two algorithms (lighting and
> tracing). At that point the question why the recursion limit is a property
> of trace will become clear.

I was just about to object, claiming that such a division would not work,
because the instance of the trace algorithm called by the radiosity algorithm
would somehow have to know the trace level of the trace that called the
radiosity code... before it dawned to me that there is an important point here,
which explains why Radiosity is (comparatively) screwed up in POV 3.6, and
finding good settings is always a pain:

Trace Level.

For the following argument, let's assume we do a maximum of 3 trace recursions,
and only a single radiosity bounce.

So now say, we trace a ray that hits the floor somewhere. Trace level 1.

We take a radiosity sample. Radiosity Bounce Level 1.

We need to trace rays for collecting the sample: Trace level 2, because that's
just how it currently works. Let's say they hit a reflecting sphere. Trace
Level 3. Let's say we hit the sky sphere.

We don't take another radiosity sample because we don't do Bounce Level 2.

No harm done so far.

Now we take another primary ray. Trace level 1 again, but this time it hits the
chrome sphere. Ray reflects, Trace level 2. Now we hit the floor again, just
beside the very first sample.

We take another radiosity sample. Radiosity Bounce Level 1 again.

Again we trace rays. Trace level 3 now. It hits the reflecting sphere - trace
limit reached, we get black color.

Huh? So we have two samples that are taken at the very same spot, at the very
same Radiosity Bounce Level, but one says the sphere is as bright as the sky,
but the other says it's pitch black...!

ARGH!

That explains a lot of dark-splotch-issues. We're doing something utterly wrong
here.

Unfortunately, using the same variable for both Trace Level and Radiosity Bounce
Level - as it is done in 3.7 beta - isn't such a good idea either: Build a
mirror somewhere, and everything reflected will use lower-quality radiosity.

So this is how it *should* be, if I'm asked:

- The Trace Level *MUST NOT* be "inherited" in any way between the "Trace"
instance calling the "RadiosityFunction" code, and the one called *by* that
code. Instead, when sampling, the Trace Level must start at 1 again (although a
different max trace level may be used, possibly even depending on Bounce Level)

- The Radiosity Bounce Level *MUST* somehow be tunnelled through a "Trace"
invocation from any calling "RadiosityFunction" to any instance that may be
called during execution of "Trace".

So yes, I was wrong - but yes, I was right that the current setup is utterly
bogus.

Will a sort of "staged" set of "Trace" and "RadiosityFunction" instances help
clean up this issue in 3.7, so that another instance of "Trace" is called for
every Radiosity Bounce Level, and each "RadiosityFunction" instance would have
a fixed bounce level to operate on?

Post a reply to this message