> Well, zeroing the threshold certainly forces the issue.  Quite
> inefficiently, though.

Agreed...

> All discontinuous regular patterns show sampling artifacts if
> rendered far enough in the distance.  This includes checkered
> planes, and since everyone is required to make the hajj to the
> checkered plane, you might search past articles to see what
> others have done.

Thanks.  I'll see what I can find.  However these artifacts
weren't really bothering me as much as gaps in the outline.
It was just a nice side-effect of the fix I used to fill in those
gaps.

> The best "solution" i know of is to avoid rendering it, e.g.,
> obscure it with ground fog, place a wall in the near
> background, or aim the camera downward a bit more.
> It's akin to what Bible illustrators do with Adam and
> Eve. ;-)  Focal blur will also do the trick, but that can
> take forever, which is what we're trying to avoid.

For this particular image I had a reason for wanting it to look
like there was nothing around for a very long ways.  See the
caption I posted with the image.  I did however look down
enough that the horizon isn't in the picture.

> Not that i know of, but you can try making the lines thicker
> to decrease the chance of the AA missing it.

Yes, but it doesn't take much before the lines look too big
in places.

> Speaking of CSG, do you have a lot of intersections and
> differences?
> Manually bounding these sometimes speeds things up.

Here I suspect you've hit the nail on the head.  I have a ton
of intersections, differences, intersections of differences,
differences of intersections and so on.  And I'm currently
not using any manual bounding.  Is there a good guide out
there for the best way to do this the most efficient way
possible?  Do you manual bound just each difference and
intersection?  What about 10 differences that are merged?
I've even seen people talk about breaking unions and merges
up into pairs so that you never put together more then 2
shapes at a time.  In the future as I learn more I'd like to go
back and clean up my code for speed as I'm sure I'll have to
before I can play with animations much but I'm not sure
what will give me the best bang for the buck and what will
be redundant or wasted effort.

> The FAQ doesn't say that you have it; it says that it's
> available. It's a freeware program that you can download
> from the Internet.  See
> http://www.faqs.org/faqs/jpeg-faq/part2/section-15.html
> for a reasonably trustworthy download site.  N.B.:  Avoid
> using long filenames with this program.

Just went back and checked.  Yes.  You are 100% correct.
"Available" was the word that I over looked.  Sorry.

> Alternatively, you can check the program that you used to
> convert your first image to JPEG, to see if it has
> supersampling control.

I'll check.

Thanks again,
Carl

Post a reply to this message

> > Well, zeroing the threshold certainly forces the issue.  Quite
> > inefficiently, though.
>
> Agreed...

You might try setting the threshold very small - say 3/256. That way, when
the rays come back virtually identical (e.g., in the middle of those big
flat grid squares ;-) POV-Ray won't bother with AA. But it should still do
it for the bright red lines. Experiment! (Theoretically, there's no point
setting it below 1/256 - unless you increase the number of bits per pixel.
Not sure if any hardware out there can display it though...)

> > Speaking of CSG, do you have a lot of intersections and
> > differences?
> > Manually bounding these sometimes speeds things up.
>
> Here I suspect you've hit the nail on the head.  I have a ton
> of intersections, differences, intersections of differences,
> differences of intersections and so on.  And I'm currently
> not using any manual bounding.  Is there a good guide out
> there for the best way to do this the most efficient way
> possible?  Do you manual bound just each difference and
> intersection?  What about 10 differences that are merged?
> I've even seen people talk about breaking unions and merges
> up into pairs so that you never put together more then 2
> shapes at a time.  In the future as I learn more I'd like to go
> back and clean up my code for speed as I'm sure I'll have to
> before I can play with animations much but I'm not sure
> what will give me the best bang for the buck and what will
> be redundant or wasted effort.

The thing to really watch out for is intersections of infinite planes, where
the intersection is finite. POV-Ray currently can't work that out; if an
intersection is between only infinite objects, POV-Ray assumes the resulting
shape is infinite too - i.e., EVERY ray is tested against it! It the
resulting object is actually small, manually bounding it will probably help
quite a bit. (On the other hand, plane intersection tests aren't that slow
to do... But they still add up. ;-)

IIRC, where you intersect an infinite object with a finite one, POV-Ray
knows the result can't be infinite. Generally POV-Ray will use the smallest
bounding volume to work out how big the result is. If you do add manual
bounding, might need to set an option to tell POV-Ray not to ignore you.
(IIRC it does that by default because older scenes tend to have this where
they [now] don't need it.)

Before I go, there's an option somewhere to turn on a useful little debug
feature. It shows the bounding volumes graphically on-screen before it
starts rendering. It will be real hard to work out which one belongs to
which object, but might be vaguely usefull. Next time you render, try using
the Draw_Vistas=on option. (You can read about it in the online help.)

Andrew.

Post a reply to this message

> You might try setting the threshold very small - say 3/256. That way,
> when the rays come back virtually identical (e.g., in the middle of
> those big flat grid squares ;-) POV-Ray won't bother with AA. But
> it should still do it for the bright red lines. Experiment!
(Theoretically,
> there's no point setting it below 1/256 - unless you increase the
> number of bits per pixel. Not sure if any hardware out there can
> display it though...)

Lets take the simple case.  If we have a flat blue background and our only
object is a very thin red cylinder, all the rays will come back blue except
the ones that the cylinder passes through.  Correct?  So if the test ray
comes back from a pixel that contained the cylinder put the test ray misses
the cylinder it will not know that it needs to perform the AA even if the
threshold is set at 1/256.  At least that was my thinking so I'm not sure I
follow your theoretical argument above.  I suspect I could render an image
with a threshold of 1/256 and again with 0 and with the right image you'd be
able to see a difference without any fancy hardware.  But yes I do need to
do more experimenting.  Its just slow going when it can take a week to
render one picture.

Ideally what I'd want to do I think is put a bounding box around the
cylinder that is atleast several pixels wide (at whatever the final
resolution is) and have a way to tell POV-Ray that any pixel that has a ray
that passes through that bounding box needs to use a given type of AA.  I'm
rather sure that isn't doable in atleast the current version.  It might be a
nice thing to suggest to the powers that be though as something to consider
adding.  As I've only been ray tracing a few months I really don't know if
that's a good suggestion or not to be honest.

> The thing to really watch out for is intersections of infinite planes,
> where the intersection is finite. POV-Ray currently can't work that
> out; if an intersection is between only infinite objects, POV-Ray
> assumes the resulting shape is infinite too - i.e., EVERY ray is
> tested against it! It the resulting object is actually small, manually
> bounding it will probably help quite a bit. (On the other hand,
> plane intersection tests aren't that slow to do... But they still add
> up. ;-)

I only have one infinite plane, which is the grid, and I don't have it
making any intersections with anything be it another plane or a finite
object.  However unless I'm missing something isn't the intersection between
two infinite planes always an infinite line.  And I don't think trying to
render that line would work.  You'd have to give it some width for it to
show up at all I think.

> IIRC, where you intersect an infinite object with a finite one,
> POV-Ray knows the result can't be infinite. Generally POV-Ray
> will use the smallest bounding volume to work out how big the
> result is. If you do add manual bounding, might need to set an
> option to tell POV-Ray not to ignore you. (IIRC it does that by
> default because older scenes tend to have this where they [now]
> don't need it.)
>
> Before I go, there's an option somewhere to turn on a useful little
> debug feature. It shows the bounding volumes graphically
> on-screen before it starts rendering. It will be real hard to work
> out which one belongs to which object, but might be vaguely
> usefull. Next time you render, try using the Draw_Vistas=on
> option. (You can read about it in the online help.)

Thanks, I will.  This sounds like a very useful feature.  Thanks for
pointing it out to me.

Carl

Post a reply to this message

"Carl Hoff" <hof### [at] wtnet> wrote in message news:401a73af@news.povray.org...
> > You might try setting the threshold very small - say 3/256. That way,
> > when the rays come back virtually identical (e.g., in the middle of
> > those big flat grid squares ;-) POV-Ray won't bother with AA. But
> > it should still do it for the bright red lines. Experiment!
> (Theoretically,
> > there's no point setting it below 1/256 - unless you increase the
> > number of bits per pixel. Not sure if any hardware out there can
> > display it though...)
>
> Lets take the simple case.  If we have a flat blue background and our only
> object is a very thin red cylinder, all the rays will come back blue
except
> the ones that the cylinder passes through.  Correct?  So if the test ray
> comes back from a pixel that contained the cylinder put the test ray
misses
> the cylinder it will not know that it needs to perform the AA even if the
> threshold is set at 1/256.  At least that was my thinking so I'm not sure
I
> follow your theoretical argument above.  I suspect I could render an image
> with a threshold of 1/256 and again with 0 and with the right image you'd
be
> able to see a difference without any fancy hardware.

OK, I see your point.

What I ment was... if you render an image with AA=1/256 and then again with
AA=1/512, you won't see a difference - unless you increase the bits/pixel
setting. However, you're quite right - setting AA = EXACTLY ZERO will make a
difference in the case of tiny objects (and other miniscule ray colour
variations).

>  But yes I do need to
> do more experimenting.  Its just slow going when it can take a week to
> render one picture.

Mmm... tell me about it! lol

> Ideally what I'd want to do I think is put a bounding box around the
> cylinder that is atleast several pixels wide (at whatever the final
> resolution is) and have a way to tell POV-Ray that any pixel that has a
ray
> that passes through that bounding box needs to use a given type of AA.
I'm
> rather sure that isn't doable in atleast the current version.  It might be
a
> nice thing to suggest to the powers that be though as something to
consider
> adding.  As I've only been ray tracing a few months I really don't know if
> that's a good suggestion or not to be honest.

Mmm... sounds good to me! But no, I don't think it's currently doable. Might
be an interestnig way to fix it though...

> > The thing to really watch out for is intersections of infinite planes,
> > where the intersection is finite. POV-Ray currently can't work that
> > out; if an intersection is between only infinite objects, POV-Ray
> > assumes the resulting shape is infinite too - i.e., EVERY ray is
> > tested against it! It the resulting object is actually small, manually
> > bounding it will probably help quite a bit. (On the other hand,
> > plane intersection tests aren't that slow to do... But they still add
> > up. ;-)
>
> I only have one infinite plane, which is the grid, and I don't have it
> making any intersections with anything be it another plane or a finite
> object.  However unless I'm missing something isn't the intersection
between
> two infinite planes always an infinite line.  And I don't think trying to
> render that line would work.  You'd have to give it some width for it to
> show up at all I think.

True - the intersection of *two* infinite planes would always be infinite.
But the intersection of, say, 4 planes could be finite. (A pyrimid, for
example!) Personally, a lot of my scenes involve generating irregular
"facetted" shapes by intersecting a few hundred planes. Slows things down a
touch if there's no manual bounding... (And then you have to figure out how
to get it RIGHT! :-S)

I don't know how your tank is constructed - if there are no infinite objects
making it up, the automatic bounding *might* be ok...

(Question to anyone else reading this... What does POV-Ray do with the
intersection of two large spheres which only slightly overlap?)

> > Next time you render, try using the Draw_Vistas=on
> > option. (You can read about it in the online help.)
>
> Thanks, I will.  This sounds like a very useful feature.  Thanks for
> pointing it out to me.

Well, you never know. ;-)

Thanks.
Andrew.

Post a reply to this message

Among other things, Carl Hoff wrote:

> Ideally what I'd want to do I think is put a bounding box around the
> cylinder that is atleast several pixels wide (at whatever the final
> resolution is) and have a way to tell POV-Ray that any pixel that has a
> ray
> that passes through that bounding box needs to use a given type of AA. 
> I'm
> rather sure that isn't doable in atleast the current version.  It might be
> a nice thing to suggest to the powers that be though as something to
> consider
> adding.  As I've only been ray tracing a few months I really don't know if
> that's a good suggestion or not to be honest.

This would be object-specific antialiasing. It has been discussed some days 
ago, it's not even trivial to define it, what should happen with 
reflections, refractions, semi-transparent surfaces...? But, somehow, I 
guess assigning the specifici antialiasing settings to simpler "bounding 
objects" would make it a bit easier (the problem with fine grids could be 
"solved")

> I only have one infinite plane, which is the grid, and I don't have it
> making any intersections with anything be it another plane or a finite
> object.  However unless I'm missing something isn't the intersection
> between
> two infinite planes always an infinite line.  And I don't think trying to
> render that line would work.  You'd have to give it some width for it to
> show up at all I think.

Remember a POV-plane is not infinitely thin, but infinitely thick, it 
divides the whole space in two regions: outside and inside. Two 
intersecting planes divide the whole space in four regions (inside both of 
them, outside both, inside only one and inside the other; the first would 
be the "intersection"), these are still infinite, but they're not 
infinitely thin, they have two faces: the surfaces of the planes. An 
intersection of four planes could (if they're are properly arranged) define 
a tetrahedron, this would be a finite shape made from infinite planes, and 
it certainly has some volume.

-- 
light_source{9+9*x,1}camera{orthographic look_at(1-y)/4angle 30location
9/4-z*4}light_source{-9*z,1}union{box{.9-z.1+x clipped_by{plane{2+y-4*x
0}}}box{z-y-.1.1+z}box{-.1.1+x}box{.1z-.1}pigment{rgb<.8.2,1>}}//Jellby

Post a reply to this message

> This would be object-specific antialiasing. It has been discussed
> some days ago, it's not even trivial to define it, what should
> happen with reflections, refractions, semi-transparent surfaces...?

My thinking is just what I said.  If a pixel has a ray (any ray be
it a reflected, refracted, or transmitted ray) penetrate the object's
bounding box then that pixel uses the specified AA.  Sounds
simple enough to me but putting it in place I'm sure is anything
but simple.  I can define it though I think.

> But, somehow, I guess assigning the specifici antialiasing settings
> to simpler "bounding objects" would make it a bit easier (the
> problem with fine grids could be "solved")

I'm not familiar with the "fine grids" problem.  Being new I think
I missed where this was talked about before.  In the
implementation I'm envisioning you'd set a global type of AA that
was used if no bounding boxes(BB) with there own specified AA
were seen for a given pixel.  Such as is done now.  The global AA
could be no AA at all.  For pixels that saw one or more BBs with
specified AA you'd pick what ever specified the most AA be it
the global setting or the setting from one of the boxes.  The default
AA on a BB would be no AA and you'd have exactly what you
have now.  That's just my 2 cents.  As I've still got alot to learn
I'm probably way over simplifying the problem.  But as the test
for the intersection of rays with BBs is already there (That's what
the BBs are for isn't it?) it to me sounds like something that might
not be too hard to add.  Hmmm... are reflected, refracted, and
transmitted rays tested against the BBs as well?  I'm not 100%
sure but something makes me think I've seen this talked about in
the documentation.

> Remember a POV-plane is not infinitely thin, but infinitely
> thick, it divides the whole space in two regions: outside and
> inside.

Thanks.  I didn't know that.  I haven't played with planes much
yet in POV-Ray.  I've used them as floors on sceens but that's
been it so far.

> Two intersecting planes divide the whole space in four regions
> (inside both of  them, outside both, inside only one and inside
> the other; the first would be the "intersection"), these are still
> infinite, but they're not infinitely thin, they have two faces: the
> surfaces of the planes. An intersection of four planes could (if
> they're are properly arranged) define a tetrahedron, this would
> be a finite shape made from infinite planes, and it certainly has
> some volume.

I follow.  That also explains Andew's comments too.  I was just
about to tell him that the intersection of 3 planes is a point and
that 4 is usually nothing.  I just haven't used planes in CSG's yet.
I think if I had an occasion to make a tetrahedron before I'd have
defined it as a prism.

Thanks,
Carl

Post a reply to this message

> What I ment was... if you render an image with AA=1/256 and then
> again with AA=1/512, you won't see a difference - unless you
> increase the bits/pixel setting.

Agreed.  Well aside from the fact that I didn't even know the
bits/pixel setting was adjustable.  I haven't had a need to play with
that yet.

> However, you're quite right - setting AA = EXACTLY ZERO will
> make a difference in the case of tiny objects (and other miniscule
> ray colour variations).

I thought I was right.  A thought hit me latter thought.  If you have a
flat backgroud the difference from pixel to pixel is also zero so you
have a is 0>0 situation.  Could this cause a floating point issue where
maybe the AA isn't done for every pixel?  Maybe the AA should be
set to -0.1?  Or maybe something like that is done internally when
the AA is set to 0.

> True - the intersection of *two* infinite planes would always be
> infinite. But the intersection of, say, 4 planes could be finite.
> (A pyrimid, for example!) Personally, a lot of my scenes involve
> generating irregular "facetted" shapes by intersecting a few
> hundred planes. Slows things down a touch if there's no manual
> bounding... (And then you have to figure out how to get it
> RIGHT! :-S)

Jellby's post cleared up the confusion this was causing me. See
my reply to his post.

> I don't know how your tank is constructed - if there are no
> infinite objects making it up, the automatic bounding *might*
> be ok...

Its a CSG of prisms, spheres, cones, tori, and boxes.  I think
that's all.  I defined all the cylinders as cones, as it was easier
for me to keep things strait in my head at the time.  That might
be costing me some rendering time too.  Do cylinders render
alot faster the cones?  I woudn't think it'd be that big of a
difference.  Oh I and do have one light source inside the
light cycle and two inside the tank so for the light to get out
all shapes are merged instead of being put together with
unions.  I'm sure that's costing me some too.  One odd
thing I have noticed is by putting a light souce inside the
objects I sometimes get a warning like "Patch objects not
allowed in intersections".  But it all works.

> (Question to anyone else reading this... What does POV-Ray
> do with the intersection of two large spheres which only slightly
> overlap?)

Good question... something I'll test with the Draw_Vistas
option you talk about below.  I'm thinking the bounding box
will be alot bigger then the small shape but I'm not sure.

I know when I was defining my models if I wanted a half
sphere I was throwing things together like this:

intersection {
  sphere {<0,0,0>, 20}
  box {<0,-1000,-1000>,<1000,1000,1000>}
}

just because I knew it would give me the shape I wanted.
Looking back at it now that MIGHT have been a very
big mistake.  Had I known planes behaved the way Jellby
pointed out I might have been using them.  It is in effect
what I'm doing above.

> Well, you never know. ;-)

I'll learn.  That's the important thing.

Thanks,
Carl

Post a reply to this message

> > What I ment was... if you render an image with AA=1/256 and then
> > again with AA=1/512, you won't see a difference - unless you
> > increase the bits/pixel setting.
>
> Agreed.  Well aside from the fact that I didn't even know the
> bits/pixel setting was adjustable.  I haven't had a need to play with
> that yet.

I doubt you will ever need to adjust the bits/pixel setting. It defaults to
24 bits per pixel, which is the maximum that any hardware I've ever seen can
display. (And even if you set it higher and had hardware that could display
it, I doubt the difference would be visible. [Which is probably WHY no such
hardware exists. ;-)])

[Enuf brackets? :-S]

> > However, you're quite right - setting AA = EXACTLY ZERO will
> > make a difference in the case of tiny objects (and other miniscule
> > ray colour variations).
>
> I thought I was right.  A thought hit me latter thought.  If you have a
> flat backgroud the difference from pixel to pixel is also zero so you
> have a is 0>0 situation.  Could this cause a floating point issue where
> maybe the AA isn't done for every pixel?  Maybe the AA should be
> set to -0.1?  Or maybe something like that is done internally when
> the AA is set to 0.

I would imagine it uses the >= operator... (Just a guess.)

> > True - the intersection of *two* infinite planes would always be
> > infinite. [SNIP]
>
> Jellby's post cleared up the confusion this was causing me. See
> my reply to his post.

Yeah, it's an easy confusion to make. ;-)

> > I don't know how your tank is constructed - if there are no
> > infinite objects making it up, the automatic bounding *might*
> > be ok...
>
> Its a CSG of prisms, spheres, cones, tori, and boxes.  I think
> that's all.  I defined all the cylinders as cones, as it was easier
> for me to keep things strait in my head at the time.  That might
> be costing me some rendering time too.  Do cylinders render
> alot faster the cones?  I woudn't think it'd be that big of a
> difference.  Oh I and do have one light source inside the
> light cycle and two inside the tank so for the light to get out
> all shapes are merged instead of being put together with
> unions.  I'm sure that's costing me some too.  One odd
> thing I have noticed is by putting a light souce inside the
> objects I sometimes get a warning like "Patch objects not
> allowed in intersections".  But it all works.

Planes have an inside and an outside. Patch objects are just surfaces - they
have no solid parts, so CGS isn't terribly useful for them. (Union should be
ok, but the intersection of that would be lines and points, like you were
expecting for planes.) Shouldn't cause an issue though - as you seem to have
found out.

The box object looks the same as the intersection of 4 planes, but is highly
optimised internally. Doing it that way should be very much faster. Since
all of your basic objects are finite, the bounding volumes shouldn't be
*too* huge... (Draw_Vistas might reveal otherwise - if you can figure out
what it's telling you!)

> > (Question to anyone else reading this... What does POV-Ray
> > do with the intersection of two large spheres which only slightly
> > overlap?)
>
> Good question... something I'll test with the Draw_Vistas
> option you talk about below.  I'm thinking the bounding box
> will be alot bigger then the small shape but I'm not sure.

That's what I'm wondering.

> I know when I was defining my models if I wanted a half
> sphere I was throwing things together like this:
>
> intersection {
>   sphere {<0,0,0>, 20}
>   box {<0,-1000,-1000>,<1000,1000,1000>}
> }
>
> just because I knew it would give me the shape I wanted.
> Looking back at it now that MIGHT have been a very
> big mistake.  Had I known planes behaved the way Jellby
> pointed out I might have been using them.  It is in effect
> what I'm doing above.

Erm... actually... a box is a finite object. In the intersection above, the
box object will probably become the exact bounding volume! If you use a
plane, I imagine POV-Ray will use the sphere as the exact bounding volume -
which is about twice as big! (Actually, having said that, I notice that that
box is rather large... in that case, POV-Ray might be using the sphere
anyway; IIRC it uses whichever is smallest. If you change that box to
{<0, -20, -20>, <+20, +20, +20>} is should render the same, but [possibly]
go faster. OTOH, maybe POV-Ray can work that out itself... I'm not sure.
Hey, try it! ;-)

> > Well, you never know. ;-)
>
> I'll learn.  That's the important thing.

Indeed. I think we're basically ALL still learning...

Andrew.

Post a reply to this message

> Planes have an inside and an outside. Patch objects are just surfaces
> - they have no solid parts, so CGS isn't terribly useful for them.
> (Union should be ok, but the intersection of that would be lines and
> points, like you were expecting for planes.) Shouldn't cause an issue
> though - as you seem to have found out.

Well the "patch" that I'm using doesn't have a surface either.  Let me
show you have I'm doing that gives me the warning.

  #declare light_stick = merge {
    sphere {<96.5, 49.5, 26.5>, 5}
    sphere {<96.5, 49.5, -26.5>, 5}
    cone {<96.5, 49.5, 26.5>, 5 <96.5, 49.5, -26.5>, 5}
  }

  #declare light_stick_P = union {
    object {light_stick}
    light_source {<96.5, 49.5, 0> White
      fade_distance 85
      fade_power 2
    }
  }

Now I take this light_stick_P and use it as part of a much more
complex CSG which is used in an intersection.  Its then that I
get the warning, but it works and the final shape still has the light
source in it.  So despite the fact that it says "Patch objects not
allowed in intersections" my patch object, the light_source lived
to tell about it.  Maybe I shouldn't be putting light sources in my
CSG's but I wanted the light fixed relative to the CSG that I
wanted to be able to scale and translate and not have to worry
about repositioning the light_source separately.  If there is a
proper way to do this I'm all ears my my way does seem to
work even though it gives me a warning.

> > Good question... something I'll test with the Draw_Vistas
> > option you talk about below.  I'm thinking the bounding box
> > will be alot bigger then the small shape but I'm not sure.
>
> That's what I'm wondering.

I'm still playing with the Draw_Vistas option and I'm still not
sure if I need the -UR flag to be able to use my manual bounding
or not.

With these options (+UD +MB0) try the following:

  #include "colors.inc"
  camera {location <-500, 0, 0> look_at <0, 85, 0> angle 36}
  light_source { <110, 5, -500> White}

  #declare rear_tire = difference {
    sphere {<0, 85, 0>, 85 scale <1,1,.2>}
    cone {<0, 85, 20>, 50 <0, 85, -20>, 60}
    cone {<0, 85, -20>, 50 <0, 85, 20>, 60}
    bounded_by { box {<-85, 0, -13>, <85, 170, 13>} }
  }

  object {rear_tire pigment {Blue}}

Now comment out the bounded_by line. You'll be able to
see the difference even without the -UR flag.

However while playing with this code using the same options:

  #include "colors.inc"
  camera {location <0, 0, -500> look_at <0, 85, 0> angle 36}
  light_source { <110, 5, -500> White}

  #declare rear_tire = difference {
    sphere {<0, 85, 0>, 85 scale <1,1,.2>}
    cone {<0, 85, 20>, 50 <0, 85, -20>, 60}
    cone {<0, 85, -20>, 50 <0, 85, 20>, 60}
    bounded_by { box {<-85, 0, -13>, <85, 170, 13>} }
  }

  #declare rear_axle = sphere {<0, 85, 0>, 17}

  #declare rear_hub = difference {
    cylinder {<0, 85, 1>, <0, 85, -1>, 60}
    object {rear_tire}
    object {rear_axle}
    bounded_by { box {<-56, 29, -2>, <56, 141, 2>} }
  }

  object {rear_hub pigment {Blue}}

I note that even with the -UR flag on, the bounding slab
size doesn't visual change from the default.

Even replace the bounded_by line with this:
    bounded_by { box {<-50, 29, -2>, <56, 141, 2>} }
    clipped_by {bounded_by}

And you will see the shape is clipped but the bounding box
hasn't moved.  I'm using [800x600,AA 0.3] if that makes
a difference.

But if I replace it with:
    bounded_by { box {<0, 29, -2>, <56, 141, 2>} }
    clipped_by {bounded_by}

Now the bounding slap IS where it should be even without
the -UR flag.

I even tried this:
    bounded_by { box {<0, 29, -2>, <56, 1000, 2>} }
    clipped_by {bounded_by}

The shape is clipped BUT the bounding slap grew back in
the x-direction and NOT in the y-direction.  Why?

I get the smallest bounding slab and the shape I want if I
take the bounded_by statement off altogether and replace
the cylinder with:
cylinder {<0, 85, 1>, <0, 85, -1>, 56}

So this Draw_Vistas option isn't behaving it what I'd consider
a predictable manner.  Is what I've seen called the bounding
slab a 2D projection of the bounding box?  It sure looks like
something else when I use:

    bounded_by { box {<0, 29, -2>, <56, 1000, 2>} }
    clipped_by {bounded_by}

And see the object clipped and I see a short fat box when
I'd expect to see a thin tall box that extends to the top of
the screen.  Can anyone tell me what is going on here?

> Erm... actually... a box is a finite object. In the intersection
> above,

True.  In my thought process I was approximating an infinite
object by making the box as large as I was.  I was doing this
because at times I was cutting more complicated CSG's in
half and I didn't want to worry about the exact size of the
CSG so I'd use a box that I knew was an order of magnitude
or more larger then my object.

> the box object will probably become the exact bounding
> volume! If you use a plane, I imagine POV-Ray will use the
> sphere as the exact bounding volume - which is about twice
> as big! (Actually, having said that, I notice that that box is
> rather large... in that case, POV-Ray might be using the
> sphere anyway; IIRC it uses whichever is smallest. If you
> change that box to {<0, -20, -20>, <+20, +20, +20>} is
> should render the same, but [possibly] go faster.

True... you get the same and when cutting a sphere in half
that's easy enough to do.  I was just begining to question if I
should go back and figure out the exact size boxes I'd need
for cutting some of my more complex CSG in half.

> OTOH, maybe POV-Ray can work that out itself... I'm not
> sure. Hey, try it! ;-)

Maybe but I'm not not sure Draw_Vistas = on is the way to
check.  Mike over in the new users area gave me this code:

#include "strings.inc"
#debug concat( VStr(min_extent(rear_tire)), "  ",
               VStr(max_extent(rear_tire)), "\n")

This may be a more direct way to answer these questions
as the relationship between the boxes drawn by the +UD
option and the bouding boxes isn't clear to me.

> Indeed. I think we're basically ALL still learning...

True... but I'm still greener then most I think.

Carl

Post a reply to this message