 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dave Kreskowiak wrote:
>
> Hi all. I took a quick look at the code fragments here and have wondered if
> anyone has seen the same thing I have.
>
> In the code, it appears that there is a bounding object for just about every
> single difference object. On top of that, what does the bounding object
> consist of? A simple box, sphere or something more complex? I guess it
> would help to see the actual code. But the thought I have is it looks like
> there is about as many bounding objects as there are primitives. If this is
> the case, here goes:
>
> In the case of bounding, more bounds is not a good thing. If your checking
> a high number of bounding objects, the speed difference, between that and
> just checking if you've hit the object itself, is lost. I had a similar
> problem with a simple lamp (a small part of the scene is attached). It's
> not a recursive object by any means, but it's simply a cone shape cut with
> another cone offset and then about 210 long boxes to cut out ribs. The
> texture is 95% transparent with an IOR about 1.25. The only light source in
> the scene is in the lamp. Cutting the shapes into the lamp shade drove the
> rendering time up from 4 hours to about 21 days!
I agree that more is not necessarily better. What drove me to my current
bounding scheme is the preliminary results I got when testing to see it
bounding offered any advantage. I had the recursion level set to one and
was rendering at a very low resolution. I noted the times with various
bounding routines and found my optimum times with the following results.
3.53 no bounding
3.30 w bounding of difference objects
3.15 w bounding around final shape and difference objects
So you can see there was a noticable improvement with the scheme I used.
The only real unknown is if at higher levels of recursion (ie more objects)
that added advantage dissapears. It could well be the case.
> Putting a bounding object around every box that cut a rib would not
> eliminate the problem because it would just be checking 210 bounding boxes.
> No speed gain there. The solution was to:
snip
> In my lamp there are 210 ribs in 10 groups of 21. This way a ray will be
> checked against a maximum of 10 bounding boxes and then a maximum of 23
> primitives (not counting IOR of course!) The tracing time went from 21 to
> 5.5 days.
>
> Dave
I would say for me there is some black art involved with this process and
have been hoping someone more informed than myself would step in and elaborate
on how pov really handles the bounding action. Perhaps it is beyond the mear
mortal to understand :)
--
Ken Tyler
See my 700+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
> I would say for me there is some black art involved with this process and
> have been hoping someone more informed than myself would step in and elaborate
> on how pov really handles the bounding action. Perhaps it is beyond the mear
> mortal to understand :)
Being a great deal less of a POV expert than Ken, I have to agree with him.
Bounding objects have always confuzzled me. If you look at the following image
(11K):
http://www.sinbad.net/~autumn/images/bounding_test.jpg
Which is more efficient? Assuming the red boxes are the bounding shapes, one can
see that the left hand item only uses one bounding shape which would make you
think that it'd render faster. However, it's also not as exact in it's bounding
limits as the group of bounding items on the right. From the conversations I've
seen regarding this topic, I'm guessing there's no concrete answer to the
question. That each instance is unique and that we have to find the right balance
between the number of bounding objects, and the exactitude of those bounding
objects. :{P
David
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David Heys wrote in message <37B31BFA.BD5BCC33@hotmail.com>...
>Ken wrote:
>
>> I would say for me there is some black art involved with this process
and
>> have been hoping someone more informed than myself would step in and
elaborate
>> on how pov really handles the bounding action. Perhaps it is beyond the
mear
>> mortal to understand :)
>
>Being a great deal less of a POV expert than Ken, I have to agree with him.
>Bounding objects have always confuzzled me. If you look at the following
image
>(11K):
>
>http://www.sinbad.net/~autumn/images/bounding_test.jpg
>
>Which is more efficient? Assuming the red boxes are the bounding shapes,
one can
>see that the left hand item only uses one bounding shape which would make
you
>think that it'd render faster. However, it's also not as exact in it's
bounding
>limits as the group of bounding items on the right. From the conversations
I've
>seen regarding this topic, I'm guessing there's no concrete answer to the
>question. That each instance is unique and that we have to find the right
balance
>between the number of bounding objects, and the exactitude of those
bounding
>objects. :{P
The theory behind bounding of objects is that for most objects, it is much
faster to check to see if a ray has hit a box enclosing the object and then
if it did check the ray against the object than it is to always check to see
if the ray has hit the object itself. However, for complex or slow to
process objects (such as julia fractals and isosurfaces), the speed
difference is so great that even more time would be saved by bounding the
object with a closer-fitting but slower object like a cylinder, sphere, or
rotated box.
Further complicating things is the fact that, for CSG operations, if the
entire resulting object is bounded by the user, each ray that intersects the
bounding object is then tested for intersections with ALL the objects making
up the CSG object. If nested CSG objects making up the object are bounded,
however, POV-Ray tests the ray against the bounds for the nested objects
before deciding which component objects to check for intersections with the
ray. This is why your multiple bounding objects in the picture will cause
it to render faster. POV-Ray is very good at automatically generating the
needed bounding box hierarchy for unions, but sometimes has trouble with
intersections or differences, which is why user bounding of these objects
sometimes speeds things up.
Hope this clarifies things.
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David Heys <cel### [at] hotmail com> wrote:
: http://www.sinbad.net/~autumn/images/bounding_test.jpg
I would use two boxes, one for the head and one for the ears.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 11 Aug 1999 11:34:31 -0400, "Dave Kreskowiak"
<dkr### [at] homecom> wrote:
>In my lamp there are 210 ribs in 10 groups of 21. This way a ray will be
>checked against a maximum of 10 bounding boxes and then a maximum of 23
>primitives (not counting IOR of course!) The tracing time went from 21 to
>5.5 days.
Hi, Dave. Interesting read. Reminded me of a simple poker chip I made
(code is long gone) and now I wonder how it would've looked using a glass
texture.
OT, thanks for the nice lampshade image. You might consider posting images
in the povray.binaries.images group and then pointing us in that direction
with your post. We'll look there. It just helps a bit to keep some
smattering of organization when, three months down the road, we scratch our
heads trying to remember where we saw this beautiful crystal lampshade.
Thanks much.
--
Alan
--------------------------------------------------------------------
http://www.povray.org - Home of the Persistence of Vision Ray Tracer
news.povray.org - where POV-Ray enthusiasts around the world can get
together to exchange ideas, information, and experiences with others
--------------------------------------------------------------------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mark Wagner wrote:<snip>
> Hope this clarifies things.
> Mark
Helps a great deal. Thanks. :{) So it basically come down to how well one
determines that POV's natural bounding process is working, and then tweek it
from there.
David
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David Heys wrote:
>
> Mark Wagner wrote:<snip>
>
> > Hope this clarifies things.
> > Mark
>
> Helps a great deal. Thanks. :{) So it basically come down to how well one
> determines that POV's natural bounding process is working, and then tweek it
> from there.
>
> David
And ultimately there is a limitation as to how much even manual or automatic
bounding can help in speeding up render times when a user such as myself pushes
the acceptable envelope of the program.
--
Ken Tyler
See my 700+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
