> > 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