I'm currently fighting with the concept of the "trace level", or rather with the
current implementation thereof.

I think that storing the current trace level as an attribute of the "Trace"
object is a very, very, very stupid idea: It should actually be an attribute of
the "Ray" object, which would make the whole thing much easier to deal with. At
least for brains wired like mine.

The same goes for the radiosity "bounce level", which as - I am currently
finding out - has totally disappeared, and is my current main suspect for the
remaining issues with some pictures.

I'll take the freedom to try and attach that radiosity "bounce level" to the ray
object, and strongly advise doing the same for the classic "trace level".

Post a reply to this message

clipka wrote:
> I'll take the freedom to try and attach that radiosity "bounce level" to the ray
> object, and strongly advise doing the same for the classic "trace level".

You really don't want to fill a lightweight class like ray with data like 
that. The recursion level is a property of the algorithm, not a ray. As 
such, moving recursion counting into the ray violates separation of data and 
algorithm, which in the long term practically always turns out to bit you 
somewhere else later when you do not expect it.

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> You really don't want to fill a lightweight class like ray with data like
> that. The recursion level is a property of the algorithm, not a ray. As
> such, moving recursion counting into the ray violates separation of data and
> algorithm, which in the long term practically always turns out to bit you
> somewhere else later when you do not expect it.

I have some years of experience as a software developer, so I know about the
pitfalls of future changes - or future maintenance for that matter. And that is
exactly the reason why I say it is a very bad idea the way it is now.

To put it on a more academic level: The choice to consider the trace level a
part of the "Trace" algorithm instead of the "Ray" data to work on has forced
an unjustifiedly close coupling between the "Trace" and "RadiosityFunction"
objects.

In fact, the trace level is part of multiple algorithms; it already shows in
your "Trace" interface: The trace level is the only changing data that is
exposed to callers. Why? Because it shouldn't be in there in the first place.
At least the "RadiosityFunction" algorithm needs it, too.

So instead of just passing it along with the ray as it is passed on from
algorithm to algorithm (e.g. from "Trace" to "RadiosityFunction" and back), the
current architecture requires that "RadiosityFunciton" must only be called by
the very same instance of "Trace" that would in turn be called by the
"RadiosityFunction" instance - and vice versa! If that isn't strong coupling, I
have never seen any. And why? All because of the "age" of the ray!

Yes, I *do* want to fill a lightweight class like ray with data like this.
Because it is inherently connected to a certain ray being processed. Just like
the information whether it is a primary ray, a radiosity ray, a photon ray, or
whatever.

If you want to keep the "Ray" class lightweight, fine - but then define a
separate kind of "companion" data object for this type of information (it could
then also contain all those flag currently in "Ray"). Misusing the "Trace"
object as a container for this information is a bad idea - and not passing it
as a parameter, but instead relying that a certain function be only called by a
certain "Trace" object, is a *very* bad one.

Post a reply to this message

clipka wrote:
> If you want to keep the "Ray" class lightweight, fine - but then define a
> separate kind of "companion" data object for this type of information (it could
> then also contain all those flag currently in "Ray"). Misusing the "Trace"
> object as a container for this information is a bad idea - and not passing it
> as a parameter, but instead relying that a certain function be only called by a
> certain "Trace" object, is a *very* bad one.

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

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. Essentially you have to see radiosity as a 
variant of the lighting algorithm that makes use of the tracing algorithm 
like all other lighting algorithms use the tracing algorithm. Basically, 
what you have is this (ignoring texturing):

intersection = trace(ray);
color = lighting(intersection);


	Thorsten

Post a reply to this message

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

I don't know about the rest of you guys, but I feel a warm feeling seeing new
blood this much interested in pov-ray nowadays.  You're doing a good job in
your observations and your itch to scratch.  Keep it up! :)

Experimentation is good.  Try it and amaze us.

Post a reply to this message

"nemesis" <nam### [at] gmailcom> wrote in message 
news:web.49564d90a6b04366180057960@news.povray.org...
>I don't know about the rest of you guys, but I feel a warm feeling seeing 
>new
> blood this much interested in pov-ray nowadays.

You know I was thinking just the same thing.
A side benefit ... It's energized me and I've been very productive with my 
doc project the past few days!

Jim

Post a reply to this message

On Sat, 27 Dec 2008 14:13:50 -0400, "Jim Holsenback" <jho### [at] hotmailcom>
wrote:

>
>"nemesis" <nam### [at] gmailcom> wrote in message 
>news:web.49564d90a6b04366180057960@news.povray.org...
>>I don't know about the rest of you guys, but I feel a warm feeling seeing 
>>new
>> blood this much interested in pov-ray nowadays.
>
>You know I was thinking just the same thing.
>A side benefit ... It's energized me and I've been very productive with my 
>doc project the past few days!
>

Me too, I've started to write tutorials for Bishop3D.
-- 

Regards
     Stephen

Post a reply to this message

> -----Original Message-----
> From: nemesis [mailto:nam### [at] gmailcom]
> I don't know about the rest of you guys, but I feel a warm feeling
> seeing new
> blood this much interested in pov-ray nowadays.  You're doing a good
> job in
> your observations and your itch to scratch.  Keep it up! :)

I'm learning more about the internals of POV then I ever did when I
experimented with the code :)

...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

"nemesis" <nam### [at] gmailcom> schreef in bericht 
news:web.49564d90a6b04366180057960@news.povray.org...
>I don't know about the rest of you guys, but I feel a warm feeling seeing 
>new
> blood this much interested in pov-ray nowadays.  You're doing a good job 
> in
> your observations and your itch to scratch.  Keep it up! :)
>
> Experimentation is good.  Try it and amaze us.
>
>

I agree! I agree! I agree!!

This is an excellent discussion and can only lead to a better POV 
ultimately.

Thomas

Post a reply to this message