While rendering some older scenes, I stumbled on this one.

The bounding don't work correctly when used in a way similar to an 
intersection.
The bounded object itself is not bounded correctly, it's as if the 
bounding object is oriented relative to the camera.
Next, there is a huge problem with the shadows: Most of the time, the 
part of the original object OUTSIDE the bounding object still cast 
shadows, but not always.
It's mostly appen when using some infinite primitive, like a quadric, 
but can also appen if the bounded object is a finite primitive or some CSG.

The following scene shows both problems.

//////////////////////////////
#version 3.7;
#include"shapes_old.inc"

plane{y,-2 pigment{rgb 1}}
union{
	object{Cylinder_X }
	object{Cylinder_Z}
	pigment{rgb<0,1,0>}
	bounded_by{box{<2,1,2><-2,-1,-2>}}
	}
box{<2,1,2><-2,-1,-2> pigment{rgbf<1,0.5,1,1>}}

light_source{ 100 rgb 1 }

camera{location<1,3,-9>*2 look_at<0,-2,0> rotate 90*y*clock}
//////////////////////////////


Alain

Post a reply to this message

Am 11.02.2013 18:01, schrieb Alain:
> While rendering some older scenes, I stumbled on this one.
>
> The bounding don't work correctly when used in a way similar to an
> intersection.
> The bounded object itself is not bounded correctly, it's as if the
> bounding object is oriented relative to the camera.
> Next, there is a huge problem with the shadows: Most of the time, the
> part of the original object OUTSIDE the bounding object still cast
> shadows, but not always.
> It's mostly appen when using some infinite primitive, like a quadric,
> but can also appen if the bounded object is a finite primitive or some CSG.

This is /not/ a bug: bounded_by is /not/ supposed to be used for visual 
effects (and never was). It is /solely/ intended for improving the 
rendering speed in cases where POV-Ray's automatic bounding mechanism 
computes far too large bounding boxes.

You may want to try clipped_by instead, or just use a proper 
intersection, depending on what you intend to achieve.

Post a reply to this message

Alain <kua### [at] videotronca> wrote:
> The bounding don't work correctly when used in a way similar to an 
> intersection.
> The bounded object itself is not bounded correctly, it's as if the 
> bounding object is oriented relative to the camera.
> Next, there is a huge problem with the shadows: Most of the time, the 
> part of the original object OUTSIDE the bounding object still cast 
> shadows, but not always.
> It's mostly appen when using some infinite primitive, like a quadric, 
> but can also appen if the bounded object is a finite primitive or some CSG.

I haven't tested your scene, but I think you have a slight
misunderstanding about what bounding objects do.

A bounding object is *not* the same thing as an intersection with an
"invisible" object. It cannot be used to "cut away" parts of an object
because that's not how it works (nor is it intended for that purpose.)

What happens is that when a ray is tested against the object, it will
first be tested against its bounding object, and if it hits that, then
it will be tested against the actual object. This test doesn't actually
care where the bounding object is. Regardless of where it is, it just
tests to see if the ray its hit, and proceeds with the actual intersection
test only if that was so.

From this it follows that if the bounding object does not actually fully
enclose the actual object, you'll get incorrect rendering (the visible
parts of the object will depend on the orientation of the bounding object
with respect the direction of the rays' origin.)

If you want to actually clip the object with another, use clipped_by,
which has been designed for that exact purpose.

And in fact, given that wanting to both bound and clip with the same
object, there's a handy shortcut, namely "clipped_by { bounded_by }"

-- 
                                                          - Warp

Post a reply to this message

Le 2013-02-11 12:40, Warp a écrit :

>
> I haven't tested your scene, but I think you have a slight
> misunderstanding about what bounding objects do.
>
> A bounding object is *not* the same thing as an intersection with an
> "invisible" object. It cannot be used to "cut away" parts of an object
> because that's not how it works (nor is it intended for that purpose.)
>
> What happens is that when a ray is tested against the object, it will
> first be tested against its bounding object, and if it hits that, then
> it will be tested against the actual object. This test doesn't actually
> care where the bounding object is. Regardless of where it is, it just
> tests to see if the ray its hit, and proceeds with the actual intersection
> test only if that was so.
>
>  From this it follows that if the bounding object does not actually fully
> enclose the actual object, you'll get incorrect rendering (the visible
> parts of the object will depend on the orientation of the bounding object
> with respect the direction of the rays' origin.)
>
> If you want to actually clip the object with another, use clipped_by,
> which has been designed for that exact purpose.
>
> And in fact, given that wanting to both bound and clip with the same
> object, there's a handy shortcut, namely "clipped_by { bounded_by }"
>

What I've done is merely reproducing what I found to be causing some 
problem in an older scene from someone else that I rendered at a larger 
resolution and some added features.
Apparently, there was a time when this was commonly used.

I KNOW that bounded_by is not intended for that use.

One of the problems seems to be that, some shadow rays that /never 
reatch/ the bounding object /do/ generate shadows.
If you render the provided scene, you'll see shadows in areas that are 
visible far from the visible part.


Alain

Post a reply to this message

Le 2013-02-11 12:40, Warp a écrit :
> Alain <kua### [at] videotronca> wrote:
>> The bounding don't work correctly when used in a way similar to an
>> intersection.
>> The bounded object itself is not bounded correctly, it's as if the
>> bounding object is oriented relative to the camera.
>> Next, there is a huge problem with the shadows: Most of the time, the
>> part of the original object OUTSIDE the bounding object still cast
>> shadows, but not always.
>> It's mostly appen when using some infinite primitive, like a quadric,
>> but can also appen if the bounded object is a finite primitive or some CSG.
>
> I haven't tested your scene, but I think you have a slight
> misunderstanding about what bounding objects do.
>
> A bounding object is *not* the same thing as an intersection with an
> "invisible" object. It cannot be used to "cut away" parts of an object
> because that's not how it works (nor is it intended for that purpose.)
>
> What happens is that when a ray is tested against the object, it will
> first be tested against its bounding object, and if it hits that, then
> it will be tested against the actual object. This test doesn't actually
> care where the bounding object is. Regardless of where it is, it just
> tests to see if the ray its hit, and proceeds with the actual intersection
> test only if that was so.
>
>  From this it follows that if the bounding object does not actually fully
> enclose the actual object, you'll get incorrect rendering (the visible
> parts of the object will depend on the orientation of the bounding object
> with respect the direction of the rays' origin.)
>
> If you want to actually clip the object with another, use clipped_by,
> which has been designed for that exact purpose.
>
> And in fact, given that wanting to both bound and clip with the same
> object, there's a handy shortcut, namely "clipped_by { bounded_by }"
>
An image is posted on p.b.images

Post a reply to this message

Am 12.02.2013 03:22, schrieb Alain:

> What I've done is merely reproducing what I found to be causing some
> problem in an older scene from someone else that I rendered at a larger
> resolution and some added features.
> Apparently, there was a time when this was commonly used.

... which was a bad idea to do, and it apparently took a while to 
convince people to cease doing it, yes.

> I KNOW that bounded_by is not intended for that use.

Then you should know better than to call it a bug (unless of course you 
call it a bug of the scene file).

> One of the problems seems to be that, some shadow rays that /never
> reatch/ the bounding object /do/ generate shadows.
> If you render the provided scene, you'll see shadows in areas that are
> visible far from the visible part.

I can well imagine this happening, due to shadow caching: Each render 
thread keeps track, on a per light source basis, of the last opaque 
object it found to block that particular light source. This very object 
will be tested first for the next shadow test. Apparently the bounding 
box test is bypassed in this case, and I can actually imagine reasons 
for doing so.

Post a reply to this message

Am 12.02.2013 03:23, schrieb Alain:

> An image is posted on p.b.images

Fits exactly with what I'd expect from the shadow caching mechanism. I 
didn't check, but you'll probably find that the "steps" in the shadow 
perfectly align with the render block grid. You'll probably also find 
that using "+WT1" will significantly change the pattern. You might also 
check what happens if you use a bit of transparency on the object; the 
"steps" should disappear in that case, because non-opaque objects don't 
take part in shadow caching.

Once again: This is not a bug, but the side effect of a misused feature.

And to cut this discussion short: It will /not/ be worked around in the 
POV-Ray code, because that would require breaking or at least degrading 
one or two performance optimization mechanisms.

Post a reply to this message

Le 2013-02-12 05:10, clipka a écrit :
> Am 12.02.2013 03:23, schrieb Alain:
>
>> An image is posted on p.b.images
>
> Fits exactly with what I'd expect from the shadow caching mechanism. I
> didn't check, but you'll probably find that the "steps" in the shadow
> perfectly align with the render block grid. You'll probably also find
> that using "+WT1" will significantly change the pattern. You might also
> check what happens if you use a bit of transparency on the object; the
> "steps" should disappear in that case, because non-opaque objects don't
> take part in shadow caching.
>
> Once again: This is not a bug, but the side effect of a misused feature.
>
> And to cut this discussion short: It will /not/ be worked around in the
> POV-Ray code, because that would require breaking or at least degrading
> one or two performance optimization mechanisms.
>

OK, case closed.

Next step: go hunting for those missused bounded_by and rewrite the 
scene using intersections, differences and clipped_by.

Post a reply to this message