POV-Ray : Newsgroups : povray.newusers : Draw Vistas Option : Re: Draw Vistas Option Server Time
30 Jul 2024 22:16:52 EDT (-0400)
  Re: Draw Vistas Option  
From: Mike Williams
Date: 2 Feb 2004 00:57:16
Message: <hQvAYCAgNeHAFwGJ@econym.demon.co.uk>
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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.