All,

I was reading through the Documentation, when I came upon the section
"clipped_by", which has an illustration along with it. According to the
documentation, clipped_by will clip off any part of the first object that is
not inside the second object. However, looking at the illustration that goes
with it, it seems that whatever is inside the second object will be clipped
off.

Am I just looking at this wrong or what?

Cheers,
Peter Ketting

Post a reply to this message

Peter Ketting <pet### [at] notmyrealboxcom> wrote:
> I was reading through the Documentation, when I came upon the section
> "clipped_by", which has an illustration along with it. According to the
> documentation, clipped_by will clip off any part of the first object that is
> not inside the second object. However, looking at the illustration that goes
> with it, it seems that whatever is inside the second object will be clipped
> off.

  clipped_by works like intersection, except that the clipping object
will not leave any surface.
  I think that would be a compact way of saying it in the documentation
as well.

  If the image shows anything else, then the image is wrong.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3f1ec7ae@news.povray.org...
> Peter Ketting <pet### [at] notmyrealboxcom> wrote:
> > I was reading through the Documentation, when I came upon the section
> > "clipped_by", which has an illustration along with it. According to the
> > documentation, clipped_by will clip off any part of the first object
that is
> > not inside the second object. However, looking at the illustration that
goes
> > with it, it seems that whatever is inside the second object will be
clipped
> > off.
>
>   clipped_by works like intersection, except that the clipping object
> will not leave any surface.
>   I think that would be a compact way of saying it in the documentation
> as well.
>
>   If the image shows anything else, then the image is wrong.

It is... although, oddly enough, it indicates what I would expect to see.
But then I'm always confusing this sort of CSG in practice.

bounded_by and clipped_by are fairly interchangeable in how they operate,
IIRC, which is why they can use shortcuts applied to each other. As is
known, bounded_by retains the inner regions from the object being used for
the bounding, therefore clipped_by will do the same.

The graphic in question is apparently in section 6.5.9.1 Clipped_By (note
that the capitalization of these letters should probably be changed so as
not to confuse people, and which I believe happens throughout the
documentation but not sure if this escaped usual convention for sake of
subject titling).

Object A could be shown as a dotted line, perhaps, and only the remaining
clipped portion within object B as a solid line. Right now it shows it as
dashed same as the clipping object. Amazing how this went overlooked before,
guess I tend to scan over such things so quickly that I fail to notice.

Bob H.

Post a reply to this message

Hughes, B. <omn### [at] charternet> wrote:
> As is
> known, bounded_by retains the inner regions from the object being used for
> the bounding, therefore clipped_by will do the same.

  Actually it's a bit more complicated than that... :)

  Due to how it works, a bounding object can be in a completely different
location than the object it is bounding (that is, the object it is
bounding is nowhere inside the bounding object), yet the object can
still be visible (eg. if the bounding object is between the camera and
the bounded object).
  This is not the case with clipped_by: If the clipped object is nowhere
inside the clipping object, it will not be visible in any case.

  This behaviour of bounding objects allows some cool tricks to be done.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message news:3f2146f0@news.povray.org...
>
>   Due to how it works, a bounding object can be in a completely different
> location than the object it is bounding (that is, the object it is
> bounding is nowhere inside the bounding object), yet the object can
> still be visible (eg. if the bounding object is between the camera and
> the bounded object).

Can you elaborate? How/why is a bounded object still visible even when the
bounding object does not intersect with it? I can think of a couple of
possibilities, but in each case I can think of a reason why it wouldn't work if
the code was logical FMHPOV*.

*from my humble point of view....

Post a reply to this message

In article <3f2152fa$1@news.povray.org>,
 "Tom Melly" <tom### [at] tomandlucouk> wrote:

> Can you elaborate? How/why is a bounded object still visible even when the
> bounding object does not intersect with it? I can think of a couple of
> possibilities, but in each case I can think of a reason why it wouldn't work 
> if the code was logical FMHPOV*.

The code only cares about whether or not the bounding object was hit, 
not about the distance of the hit. If, from the camera's point of view, 
the bounding shape covers the image area of the object, the object will 
be visible. It doesn't care if the bounding shape is actually in front 
or behind the object. However, from the point of view of a light source 
in the same scene, the bounding shape is nowhere near its object, so it 
just doesn't see the object.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

"Christopher James Huff" <cja### [at] earthlinknet> wrote in message
news:cja### [at] netplexaussieorg...
> In article <3f2152fa$1@news.povray.org>,
>  "Tom Melly" <tom### [at] tomandlucouk> wrote:
>
> > Can you elaborate? How/why is a bounded object still visible even when
the
> > bounding object does not intersect with it? I can think of a couple of
> > possibilities, but in each case I can think of a reason why it wouldn't
work
> > if the code was logical FMHPOV*.
>
> The code only cares about whether or not the bounding object was hit,
> not about the distance of the hit. If, from the camera's point of view,
> the bounding shape covers the image area of the object, the object will
> be visible. It doesn't care if the bounding shape is actually in front
> or behind the object. However, from the point of view of a light source
> in the same scene, the bounding shape is nowhere near its object, so it
> just doesn't see the object.

Ah yes, such is raytracing. I wasn't even thinking about that aspect, only
the physical cutting away or containment of objects acting on other objects.
Maybe that's about what Tom could be saying to himself now, too.  :-)

Bob H.

Post a reply to this message

"Christopher James Huff" <cja### [at] earthlinknet> wrote in message
news:cja### [at] netplexaussieorg...
>
> The code only cares about whether or not the bounding object was hit,
> not about the distance of the hit. If, from the camera's point of view,
> the bounding shape covers the image area of the object, the object will
> be visible. It doesn't care if the bounding shape is actually in front
> or behind the object. However, from the point of view of a light source
> in the same scene, the bounding shape is nowhere near its object, so it
> just doesn't see the object.
>

This was one of the possibilities I considered, but I couldn't work out why this
was efficient.

Doesn't it imply that more tests will have to be done than if the ray was only
checked for intersections with the object when the ray was inside the container?

Hmm, looking at that last sentence, I'm beginning to suspect that the notion of
"more tests" if fundementally flawed.

Post a reply to this message

In article <3f24e28c$1@news.povray.org>,
 "Tom Melly" <tom### [at] tomandlucouk> wrote:

> This was one of the possibilities I considered, but I couldn't work out why 
> this was efficient.

For POV-Ray's algorithm, having the depth of the bounding shape is of no 
benefit and finding it can take additional computations over a simple 
hit/no hit test.


> Doesn't it imply that more tests will have to be done than if the ray 
> was only checked for intersections with the object when the ray was 
> inside the container?

If you did that, the vast majority of objects will be invisible. The 
camera is rarely inside the bounds of an object. It is very uncommon for 
a ray to hit an object which has a bounds that contains the origin of 
the ray.

If the ray originates inside the bounding shape, you may as well assume 
the bounding shape has been hit, no matter what the direction...there is 
no need to actually intersect with the bounds. Is this what you were 
thinking?


> Hmm, looking at that last sentence, I'm beginning to suspect that the notion 
> of "more tests" if fundementally flawed.

I'm not sure what you're thinking of or how you're trying to apply that 
idea. I have built a raytracer that does use the depths of the bounds 
intersections: if the bounds intersection of a shape is further than the 
current best intersection, it doesn't bother to do a full intersection 
test. I haven't tested it to see how much of an improvement there is, if 
there is any at all, because it does require additional work to manage 
the extra information.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

"Christopher James Huff" <cja### [at] earthlinknet> wrote in message
news:cja### [at] netplexaussieorg...
>
> I'm not sure what you're thinking of or how you're trying to apply that
> idea. I have built a raytracer that does use the depths of the bounds
> intersections: if the bounds intersection of a shape is further than the
> current best intersection, it doesn't bother to do a full intersection
> test. I haven't tested it to see how much of an improvement there is, if
> there is any at all, because it does require additional work to manage
> the extra information.

My assumption (which afaik is/was wrong) was that the bounding box had a
similiar function to the container for an iso-surface (where I may also have
missed the point), i.e. that you only evaluate the shape for points inside the
container, thus saving calculations on points outside the bounding box.

I hadn't realised (and still don't really understand) that the bounding box for
an object has more to do with the camera's interaction with the shape, rather
than just defining the maximum possible extent of the shape.

In other words, you wouldn't bother to evaluate whether the ray had hit, for
example, a sphere for any point outside the sphere's bounding box.

Post a reply to this message