"Kenneth" <kdw### [at] earthlinknet> wrote:
> If an area_light has a looks_like object, and that object is as large or larger
> than the area_light grid size, the render takes at least twice as long as
> without it, for even the simplest object. (The entire image takes longer to
> render.)  It's as if the program is doing some unneeded calculations (shadow
> calculations?) even though the object has an implied no_shadow. Actually, this
> slow-down occurs with *any* no_shadow object that happens to invade the
> area_light's 'volume of space.'
>
> The problem only shows up if automatic bounding is on; otherwise not. (Since
> most scenes have enough objects to turn it ON, it's definitely annoying.) For
> my tests, I turned Bounding_Threshold to zero (so it's 'on' regardless of the
> number of objects), then switched Bounding on or off.

I had a look at the code; obviously, when bounding is ON, POV "shoots first and
asks later": It first performs bounding tests using some standard core
functions, and filters out objects flagged with no_shadow later.

The reason that a smaller looks_like object speeds things up may be related to
the way POV does bounding box tests (didn't look at this, but e.g. POV might
first test whether a ray starts outside the box and faces away from it, before
testing whether and where it might actually intersect the faces of the box).

There seems to be another instance where the no_shadow flag is only tested after
some calculations have already been performed, which is when bounding is OFF and
the object in question is part of a CSG object.

(So basically, the only situation in which the no_shadow flag is actually tested
first, is when bounding is OFF and the object in question is a "root" object.)


From what I see in the 3.7 beta code, these issues have been addressed, by
building the no_shadow and similar filters into the core functions that
actually do the bounding box and intersection tests.

Post a reply to this message