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

clipka wrote:
> 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?

Well, it does not (fully, at least) explain why some scenes are brighter in 
3.7 in some areas.  It could indeed explain the dark spots though.

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> Well, it does not (fully, at least) explain why some scenes are brighter in
> 3.7 in some areas.  It could indeed explain the dark spots though.

I haven't figured that one out yet, but at the moment I suspect side effects
from other parts of the lighting model. I'm getting quite close to the original
3.6 code at the moment, as far as the radiosity stuff goes.

One thing I noticed was that the balcony scene, when rendered without photons,
does not show the shadow of the drink, so obviously there's some more work to
be done than just radiosity.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> One thing I noticed was that the balcony scene, when rendered without photons,
> does not show the shadow of the drink, so obviously there's some more work to
> be done than just radiosity.

Perhaps not.  I remember one day rendering a glass scene with and without
photons (no radiosity) and was astounded to realize that glass without
refraction and caustic would feature very little shadow after all.  It makes
sense:  caustics are the result of bent rays of light passing through the glass
and gathering at a single point or region, so the other parts of the occluded
"shadow" should really show much darker, since the light is not directly going
through the transparent material as in the no refraction/caustics image...

Post a reply to this message

"nemesis" <nam### [at] gmailcom> wrote:
> > One thing I noticed was that the balcony scene, when rendered without photons,
> > does not show the shadow of the drink, so obviously there's some more work to
> > be done than just radiosity.
>
> Perhaps not.  I remember one day rendering a glass scene with and without
> photons (no radiosity) and was astounded to realize that glass without
> refraction and caustic would feature very little shadow after all.  It makes
> sense:  caustics are the result of bent rays of light passing through the glass
> and gathering at a single point or region, so the other parts of the occluded
> "shadow" should really show much darker, since the light is not directly going
> through the transparent material as in the no refraction/caustics image...

There's something wrong with your argument:

- This is not just plain water, but some orange-ish drink. We can plainly see
the colour, so it should cast a corresponding coloured shadow.

- In 3.6, it *does* cast the expected shadow when photons are off. In 3.7 it
doesn't: I imagine being able to make out an ever so slight shadow from the
glass itself, but nothing at all from the drink in it.

(BTW, when I talk about "photons being turned off", I actually mean the scene
file being changed to "#declare Photons=off" (or whatever that file happens to
use for it), not disabling photons through INI file quality settings)

Post a reply to this message