strange behaviour, may be only radiance or ma cosx?

Saved you? As the creator of the shadow cache, which was the source of this error, I think I was the spoiler in this case....

It was a subtle bug, though -- not the usual stupid one. Because of the way the shadow cache works, it only tests for intersection with a suspected blocker, assuming that any intersection with the potential blocker implies that it is in the way of the source. In the case of a sphere with a source inside, a ray directed towards the source will also intersect the opposite side of the sphere, but not after passing through the source -- a condition I wasn't checking for (until now). The same thing would have happened with a cone or cylinder with a source inside, though I obviously never tested these cases either, as I hadn't noticed the problem before, and I'm sure it was there from the start.

I had assumed that since I was working on the shadow cache earlier this week, that I had made some silly mistake in my changes, which is what threw me off in my debugging. I wish I had a decent debugging environment -- what I have is the old hacker's fallback: fprintf().

-Greg

P.S. You can download the latest check-in of srcobstr.c from:

  http://www.radiance-online.org/cgi-bin/viewcvs.cgi/ray/src/rt/srcobstr.c

It will be included in tomorrow's HEAD release.

···

From: Giulio Antonutto <[email protected]>
Date: September 10, 2004 8:54:14 AM PDT

Thanks, as usual you saved all us!
spider-greg or super-greg?
See you soon in Fribourg,
regards,
giulio

Dear Radiance Alpha Testers:

Make sure you download the new version of srcobstr.c I just checked in -- 2.10, because I introduced an even worse bug in my last fix that caused an internal error for distant sources.

-Greg

···

From: Greg Ward <[email protected]>
Date: September 10, 2004 9:13:30 AM PDT

Saved you? As the creator of the shadow cache, which was the source of this error, I think I was the spoiler in this case....

It was a subtle bug, though -- not the usual stupid one. Because of the way the shadow cache works, it only tests for intersection with a suspected blocker, assuming that any intersection with the potential blocker implies that it is in the way of the source. In the case of a sphere with a source inside, a ray directed towards the source will also intersect the opposite side of the sphere, but not after passing through the source -- a condition I wasn't checking for (until now). The same thing would have happened with a cone or cylinder with a source inside, though I obviously never tested these cases either, as I hadn't noticed the problem before, and I'm sure it was there from the start.

I had assumed that since I was working on the shadow cache earlier this week, that I had made some silly mistake in my changes, which is what threw me off in my debugging. I wish I had a decent debugging environment -- what I have is the old hacker's fallback: fprintf().

-Greg

P.S. You can download the latest check-in of srcobstr.c from:

  http://www.radiance-online.org/cgi-bin/viewcvs.cgi/ray/src/rt/srcobstr.c

It will be included in tomorrow's HEAD release.