 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
No solution for the bounding problem but here is another approch : could you
prevent the apparition of unecessary (invisible) objects (on the basis of their
position in space for instance) ? I've done this a couple of times (for my madpipe
macro for instance) and it can cut down drastically your number of objects. Of
course it may not be feasible in your case.
Another solution I'm using a lot these days is to export systematically
procedure-generated objects like this to an inc file so that I can play with them
without having to parse things again and again. Also, I can remove objects
directly from the inc file. With a recursion macro, you could store each recursion
level objects in their own file.
Gilles Tran
Ken wrote:
> Greetings Advanced Users !
>
> I have a scene rendering that has been going now for 24 hours. It has
> several levels of recursion and has deeply nested CSG operations. To
> decrease the rendering time I added manual bounding to the differencing
> objects. This gave me a decent increase of rendering time at 1 level of
> recursion when I was testing to see if manual bounding would help.
>
> However since I bumped the recursion level up to a depth of 5 my
> render time has decreased to a point of being unacceptable and I am
> likely to stop my current session and just give up on it. I calculate
> at it's current rendering rate of 4 hours per line with 412 lines to
> go it will take 69 days to finish. My question then is should I turn
> automatic bounding off when manual bounding has been used in the scene
> file or will the manual bounding simply override any automatic bounding
> that would normally occur ?
>
> In my current bounding scheme I have the objects that are subtracting
> from the original shape bounded individually and I have also bounded the
> shape that is being differenced. Another question would be is when to bound
> a shape in an operation for optimum performance. There are often several
> ways of adding bounding and I am not sure when or where it should be
> applied. Will manual bounding at the wrong place hurt the process when
> a certain number of csg operations if reached as opposed to being an aid
> in a simple operation ?
> I would be more than happy to post the source for anyone willing to look
> at it but it is a bit lengthy to add to this post without first seeing an
> interest in it.
>
> A skeleton example of the bounding scheme I am currently using is:
>
> // the cutting objects
> #declare Diff_shape =
>
> intersection {
> object { obj1 }
> object { obj2 }
> bounded_by {
> object { obj3 }
> }
> // bound the cutting shape
> #declare Diff_Shape_bound = object { Diff_Shape }
>
> // The shape being cut
> #declare Diff_Obj = object { obj4 }
>
> // A bounding shape for the shape being cut
> #declare Diff_Obj_Bound = object { Diff_Obj }
>
> Then I have a complicated recursive while loop to difference the Diff_obj.
>
> // The differencing operation
> #declare Final_Shape =
> difference {
> Loop stuff
> object { Diff_Obj }
> union {
> object { Diff_Shape }
> bounded_by {
> object { Diff_Shape_bound }
> }
> #end loop stuff }
>
> // And finaly bound the entire object after the difference operation.
> object { Final_Shape
> bounded_by {
> object { Diff_Obj_Bound }
> }
>
> Is this complicating things overly much ? It really seemed to help when I used
> lower recursion depths but when going higher it has basicaly stalled out.
>
> --
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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!
What I found in my case was this (I THINK my analysis is right, if not say
so!! ;) CSG's are automatically bounded by POV by default. This meant that
whenever a ray hit the bounding box the ray would be checked against every
primitive inside the box. In my case that's 212 objects, plus an IOR. This
meant that I had to come up with a better bounding scheme.
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:
- Turn off POV's automatic bounding.
- NOT bound the entire shade in a box
there is a light in it and all rays will hit it anyway!
- Group a bunch of adjacent ribs together with a union and then
bound that union with a box.
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
Ken <tyl### [at] pacbell net> wrote in message
news:37B### [at] pacbellnet...
>
> Greetings Advanced Users !
>
> I have a scene rendering that has been going now for 24 hours. It has
> several levels of recursion and has deeply nested CSG operations. To
> decrease the rendering time I added manual bounding to the differencing
> objects. This gave me a decent increase of rendering time at 1 level of
> recursion when I was testing to see if manual bounding would help.
Post a reply to this message
Attachments:
Download 'Lamp.jpg' (14 KB)
Preview of image 'Lamp.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken <tyl### [at] pacbellnet> wrote:
: Here you go Warp. The software at this site will allow you to automaticaly
: reformat my badly indented code into an indented format of your choice :)
Actually your indentation style reflects your personality. I think it
would be insulting to modify your expressive talent. I would be seeing
a fake Ken.
Keep up with your own style. If I whine sometimes, don't let it bother
you :)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] hotmailcom> 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
|
|
| |
| |
|
|
|
|
| |
