> I don't think that scaling ever slows down any ray tests. What
> happens is that all the scaling, rotations and translations for an
> object are combined during parsing into a single transformation
> matrix. Applying the resulting matrix goes at the same speed
> whatever type of transformation is being applied.

Interesting... But is this case you are then fitting a scaled sphere
inside a scaled sphere bounding shape and telling me its faster
when its bound by a box.  What sort of shape would render
faster being bound by a sphere if its not a sphere?  It doesn't
sound like using a sphere as a bounding shape would be all that
useful.  I assume I'm missing something.

Carl

Post a reply to this message

> One of the things that is going on is that POV-Ray is reasonably
> smart about knowing when it is likely to be helpful to remove
> manual bounding. +UR doesn't remove all manual bounds, only
> manual bounds where POV-Ray thinks it can do better. In this
> case, it has trusted you to provide better manual bounds than it
> would have applied automatically.

Bases on what you say below I assume "better" in this case means
lower volume.  I'd think cross-sectional area relative to the camera
would be a better judge of quality but I'm sure its much easier to
calculate volume.  I think I can follow.  +UR doesn't force the
manual bounds to be removed it just forces this quality check.

> In this case, the automatic bounding box calculated by
> POV-Ray is *considerably* better than the one you provided
> manually.

Volume wise yes but mine shound have had a smaller bounding
slab with the +UD option which I think means that particular
picture would have rendered faster as fewer pixels would have
been checked for ray intersection with that shape.

By the way the reason I didn't use:
    bounded_by { box {<-56, 29, -1>, <56, 141, 1>} }

is I was worred about Co-incident Surface problems.  Note
what happens if you use:
    bounded_by { box {<-56, 29, -1>, <56, 141, 1>} }
    clipped_by {bounded_by}

Should this not be an issue if just the bounded_by statement
is used?

> I would have though that -UR would force it to use the manual
> bounding. However, the documented reason why you would
> want to keep inefficient manual bounds doesn't apply in this
> case, and perhaps POV-Ray is smart enough to have worked
> that out.

So even with the -UR flag you are telling me it does the quality
check and uses what it thinks is better?  So just what is the
difference between -UR and +UR?  Is there one?

> Your manual bounding box has a volume of 50,176 cubic
> units, whereas the automatic bounds calculated by POV-Ray
> has a volume of 28800 cubic units.

I'm guessing 120*120*2.

> A quick experiment shows that POV-Ray is choosing the
> bounds that have the lower volume irrespective of the UR
> setting.

Interesting... sounds like you are coming to the same
conclusion I am.  That being the the UR flag isn't doing
anything.

> Try making the Z values of your manual bounding box a
> closer fit.

Done... and yes it works.  I see the default bounding box has
Co-incident surfaces so I take that to mean I can use them
too.

Thanks,
Carl

Post a reply to this message

Wasn't it Carl Hoff who wrote:

>Bases on what you say below I assume "better" in this case means
>lower volume.  I'd think cross-sectional area relative to the camera
>would be a better judge of quality but I'm sure its much easier to
>calculate volume.  I think I can follow.

Such a cross section area might be better for the vista buffers,
but the bounds are often used when considering rays from other
directions, for example when tracing shadows and reflections.

>  +UR doesn't force the
>manual bounds to be removed it just forces this quality check.

My experiments show that, in this situation, the check happens with both
+UR and -UR. I'm beginning to wonder if they've sneakily removed the UR
functionality and forgotten to remove it from the documentation.

>> In this case, the automatic bounding box calculated by
>> POV-Ray is *considerably* better than the one you provided
>> manually.
>
>Volume wise yes but mine shound have had a smaller bounding
>slab with the +UD option which I think means that particular
>picture would have rendered faster as fewer pixels would have
>been checked for ray intersection with that shape.

Tight bounds are generally more important than tight vista buffers. In
this case, if you force POV to use those manual bounds (not easy) then
it runs 40% slower than using the automatic bounds. POV was right to
overrule you. This remains true even if you move the light source to the
same location as the camera (causing the shadow rays to point in the
same direction as the viewing rays). POV's automatic bounds are still
faster if there are no light in the scene.

>
>By the way the reason I didn't use:
>    bounded_by { box {<-56, 29, -1>, <56, 141, 1>} }
>
>is I was worred about Co-incident Surface problems.  Note
>what happens if you use:
>    bounded_by { box {<-56, 29, -1>, <56, 141, 1>} }
>    clipped_by {bounded_by}
>
>Should this not be an issue if just the bounded_by statement
>is used?

It's not an issue for bounded_by, but clipped_by is a CSG operation and
therefore it is an issue for that.


Even with these slightly more complicated objects, you are spending
hours of effort to make optimisations that are saving about 0.05 seconds
of tracing time.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Wasn't it Carl Hoff who wrote:
>> I don't think that scaling ever slows down any ray tests. What
>> happens is that all the scaling, rotations and translations for an
>> object are combined during parsing into a single transformation
>> matrix. Applying the resulting matrix goes at the same speed
>> whatever type of transformation is being applied.
>
>Interesting... But is this case you are then fitting a scaled sphere
>inside a scaled sphere bounding shape and telling me its faster
>when its bound by a box.  What sort of shape would render
>faster being bound by a sphere if its not a sphere?  It doesn't
>sound like using a sphere as a bounding shape would be all that
>useful.  I assume I'm missing something.

Here's a rather artificial case where a bounding sphere is faster

#include "functions.inc"
camera { location  <0, 0, -4> look_at <0, 0, 0> angle 50}
light_source {<-100,200,-100> colour rgb 1}

#declare Thing =
isosurface {
  function { x*x + y*y + z*z - 1 + f_noise3d(x*10, y*10, z*10)*0.3}
        max_gradient 5
        contained_by{sphere{0,2}}
        pigment {rgb 1}
  bounded_by {box {-1,1}}        
  //bounded_by {sphere {0,1}}
}

object {Thing}

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

> Here's a rather artificial case where a bounding sphere is faster
>
> #include "functions.inc"
> camera { location  <0, 0, -4> look_at <0, 0, 0> angle 50}
> light_source {<-100,200,-100> colour rgb 1}
>
> #declare Thing =
> isosurface {
>   function { x*x + y*y + z*z - 1 + f_noise3d(x*10, y*10, z*10)*0.3}
>         max_gradient 5
>         contained_by{sphere{0,2}}
>         pigment {rgb 1}
>   bounded_by {box {-1,1}}
>   //bounded_by {sphere {0,1}}
> }
>
> object {Thing}

Thanks... I see what I was missing now.

Carl

Post a reply to this message

> Such a cross section area might be better for the vista buffers,
> but the bounds are often used when considering rays from other
> directions, for example when tracing shadows and reflections.

True.  I was over simplifying the problem.

> My experiments show that, in this situation, the check happens
> with both +UR and -UR. I'm beginning to wonder if they've
> sneakily removed the UR functionality and forgotten to remove
> it from the documentation.

My thinking as well.

> Tight bounds are generally more important than tight vista buffers.
> In this case, if you force POV to use those manual bounds (not
> easy) then it runs 40% slower than using the automatic bounds.

Ok... may I asked how you forced it, since that is what I thought
the UR flag was for?  You've convined me that POV-Ray's
bounding was better then mine.  But I am curious how you tested
that.

> POV was right to overrule you. This remains true even if you
> move the light source to the same location as the camera
> (causing the shadow rays to point in the same direction as the
> viewing rays). POV's automatic bounds are still faster if there
> are no light in the scene.

I believe you.

> It's not an issue for bounded_by, but clipped_by is a CSG
> operation and therefore it is an issue for that.

Thanks.  That's one less thing I have to worry about.

> Even with these slightly more complicated objects, you are
> spending hours of effort to make optimisations that are saving
> about 0.05 seconds of tracing time.

True.  I'm doing this so I can learn what POV-Ray is doing.
I'll then try to optimize some of my much slower CSGs.  I'm
playing with the fast ones so I don't spend all my time waiting
whenever I make a tweak.  I know somewhere in my more
complicated CSGs there must be some big improvements to
be made.  I've got scenes that take weeks if not months to
render and they look simple compared to some of the stuff
I see posed here that takes hours.  Look at my post over in
the image area called "My second TRON subject".  I also
hope to play with animations so a 0.05 second improvement
per object per frame might pay off in the long run.  Even if
it doesn't I'm still learning alot.

Thanks for all the help,
Carl

Post a reply to this message

Wasn't it Carl Hoff who wrote:
>> Here's a rather artificial case where a bounding sphere is faster
>>
>> #include "functions.inc"
>> camera { location  <0, 0, -4> look_at <0, 0, 0> angle 50}
>> light_source {<-100,200,-100> colour rgb 1}
>>
>> #declare Thing =
>> isosurface {
>>   function { x*x + y*y + z*z - 1 + f_noise3d(x*10, y*10, z*10)*0.3}
>>         max_gradient 5
>>         contained_by{sphere{0,2}}
>>         pigment {rgb 1}
>>   bounded_by {box {-1,1}}
>>   //bounded_by {sphere {0,1}}
>> }
>>
>> object {Thing}
>
>Thanks... I see what I was missing now.

One interesting thing to note about this scene is that it behaves
differently with +UR and -UR.

With +UR, POV-Ray says "Warning: unnecessary bounding object removed"
and it renders *faster* without the bounds.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

> One interesting thing to note about this scene is that it behaves
> differently with +UR and -UR.
>
> With +UR, POV-Ray says "Warning: unnecessary bounding
> object removed" and it renders *faster* without the bounds.

That is interesting.  Any idea why?  Without any bounds doesn't
it check every ray for intersections with the object.  I would
have thought that would slow it down.

So the UR flag does do something... still not sure exactly what.

Carl

Post a reply to this message

On Sun, 1 Feb 2004 19:31:59 +0000, Mike Williams
<nos### [at] econymdemoncouk> wrote:

>Wasn't it Carl Hoff who wrote:
>
>>I find that a little surprising as the scaled sphere is a much better fit.
>>If the sphere test is slower then a box test then I'm curious when
>>using a sphere as a bounding object would actually give an
>>improvement.  Could it be the scaling that's slowing it down?

You apply a 'bounded_by' object <B> to speed up the intersection tests
in those cases where <B> and the bounded object <O> are not
intersected (which requires that intersecting <B> is cheaper than
intersecting <O>).
You have to pay for it in those cases where <B> is intersected no
matter whether <O> is hit or missed by the ray.
Now assume two candidates <B1> and <B2> as 'bounded_by' object where
<B1> is cheaper to intersect than <B2> but <B2> better fits.
The latter means <B2> generates less 'false positive' intersections
where <O> is tested but missed by the ray.
Which of both candidates is the best one depends on the intersection
costs of <O>.
If <O> intersections are really expensive (as for a complicated
difference/intersection object) the lower number of 'false positive'
intersections of <B2> will outweigh the cheaper intersections of <B1>.
This may even change during scene development where you start with a
simple <O> object and end up with a complicated one.

>I don't think that scaling ever slows down any ray tests. What happens
>is that all the scaling, rotations and translations for an object are
>combined during parsing into a single transformation matrix. Applying
>the resulting matrix goes at the same speed whatever type of
>transformation is being applied.

But not each object needs to accumulate transformations.
For example a sphere doesn't create a TRANSFORM as long as it isn't
scaled unevenly such that it becomes a more general ellipsoid.
There are more objects (plane, triangle, ...) where only under certain
circumstances transformations are created/stored and from then on
accumulated.

Andreas

Post a reply to this message