LibraryMan wrote:

> OK, as an example, here's what I get after commenting out area lights, sky
> sphere, and a not-very-complex wall object.  Is it typical to have the
> bounding box(es) take such a high percentage? (I really don't understand
> what I'm seeing here)

OK, let me see what we have here...
 

> Bicubic Patch                  1897457               0      0.00

Hmm... There's a bicubic patch somewhere in the scene, but it is not 
visible at all: no intersection tests succeeded. It might be behind the 
camera or something.


> Box                          398678261         1683150      0.42
> Cone/Cylinder                 30031777         2434654      8.11
> CSG Intersection             215095850         1551946      0.72
> CSG Merge                      1113026           18718      1.68
> CSG Union                    197475969          266424      0.13
> Torus                        589217202          120998      0.02
> Torus Bound                  589217202          151459      0.03

As you see, very few of the intersection tests with these types of objects 
succeeded. For some reason, POV is doing a _lot_ of unnecessary work, 
checking rays against complex objects, but failing to find intersection 
points.


> Bounding Box                 271143478       269643947     99.45

This is also rather strange. You seem to have a very loose bounding, with 
the actual objects taking up a very small part of the total volume of 
bounding boxes. That's why almost every ray hits a bounding box, but when 
POV then checks a ray against the objects inside the box, it fails.


Conclusion:
Most probably you have a complex CSG construct of which only a very small 
part is actually visible. POV cannot calculate an effective bounding 
solution to such an object, so it ends up making a lot of work in vain. If 
you bounded your object manually with bounded_by { } and tried to get it as 
tight as possible, the render speed would probably increase a lot.

Post a reply to this message

I acknowledge and appreciate that, but given a camera being focussed on the
SAME EXACT AREA of a scene that has only changed in complexity by, say,
15-20% (not having been too elaborate to begin with, CSG-wise):
1) the older version rendered in 3 min. 52
2) the newer version rendered in > 2 hrs!

Again, the specific area the camera is trained on (exact same location &
look_at vectors) has not really changed that much, but other objects in the
POV file must really be slowing everything down!  And they're not even
visible to the camera!! AARRGH!
Many thanks,
MMW

Tim Nikias wrote:
>Note that many CSG-operations (difference, intersection,
>merge) stacked onto (into?) each other slow down the
>calculation process a lot, because a ray has to be tested
>against all objects of the CSG.
>
....
>
>Regards,
>Tim

>

Post a reply to this message

It makes sense that the bounding is all hosed -- I'm a POV newbie (with no
programming exp.) and have never messed with manual bounding.
What do you do if your POV file is loosely organized, and spatially-nearby
objects are not necessarily described in the same part of the file? How do
you make a bounded_by statement apply to two objects that are not specified
in the same statement? (I'm posting this question before looking at the
docs, so the question itself may not make sense yet...)
--MMW

Johannes Dahlstrom wrote:

>
>This is also rather strange. You seem to have a very loose bounding, with
>the actual objects taking up a very small part of the total volume of
>bounding boxes. That's why almost every ray hits a bounding box, but when
>POV then checks a ray against the objects inside the box, it fails.
>
>
>Conclusion:
>Most probably you have a complex CSG construct of which only a very small
>part is actually visible. POV cannot calculate an effective bounding
>solution to such an object, so it ends up making a lot of work in vain. If
>you bounded your object manually with bounded_by { } and tried to get it as
>tight as possible, the render speed would probably increase a lot.
>

Post a reply to this message

web.3dab05c494823da42b597c920@news.povray.org...
> Is there some built-in POV feature that would help me diagnose which
> elements of a scene are hogging all the render time?

Usually, hogging elements can be detected just by watching the pixel line go
over them. POV-Ray doesn't refresh the render for every pixel to save time,
but it's usually enough to click repeatedly on the bottom slider to see the
pixels appear one by one when it's really slow. The slow parts become
obvious then.

What makes them slow is impossible to tell without seeing the code, though.
If it's simple CSG with simple primitives, the culprit could be either
reflections, transparencies or an object with many complex pieces taken out
by difference. Just wild guesses of course.

G.


--
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

LibraryMan <mrm### [at] attnet> wrote:
> OK, as an example, here's what I get after commenting out area lights, sky
> sphere, and a not-very-complex wall object.  Is it typical to have the
> bounding box(es) take such a high percentage? (I really don't understand
> what I'm seeing here)

  In theory, the higher the success percentage in that list, the better.
  A low percentage means that lots of rays were tested against the object
in question, but it did not hit it very often. This means that quite lot
of useless work was done.
  On the other hand, a high percentage means that that most of the rays
did hit the object and the amount of wasted work was minimal.

  However, if the success percentage of a bounding box is high but the
one of the object inside this bounding box is very small, that's usually
a sign that the bounding box is not very optimal for that object (ie.
it's way too big).
  Naturally not all objects can have an optimal bounding box (eg. if the
object is very thin and extends to a large area, like a net or something
similar).

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

I think I had a sentence saying that if there is
no need for transparency, merge{} might be
left out...

So unless you actually use discs/triangles/planes
which intersect with another area, the coincident
surface should be no problem, as these should be
on the inside of a non-transparent object. And media
also only shows up in transparent objects.

I guess you've just overread that, no offense taken.
It seems we both know the pro's and con's of merge
vs union... :-)

Regards,
Tim

--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde

> Note that, although faster with opaque objects, this might (and probably
> will) not only to be actually slower when using transparent objects (due
to
> the need for more intersection tests and, with reflection, deeper
> recursion), but also produce some artifacts such as the infamous
coincident
> surfaces problem. Using merge may help somewhat, but I don't think it gets
> rid of all the artifacts. Also, using such a composite object as a media
> container may be artifact-prone.

Post a reply to this message

Tim Nikias wrote:

> I think I had a sentence saying that if there is
> no need for transparency, merge{} might be
> left out...

Yes, of course. With opaque objects there'll no problems.

> It seems we both know the pro's and con's of merge
> vs union... :-)

Yes, so it seems :). But, my point was that with _transparent_ objects, the 
subdivision method you proposed may produce artifacts. Let's take a simple 
example:

difference {
        box { <-3,-1,-1>, <3,1,1> }
        cylinder { 2*y, -2*y, 0.8 }
}

vs.

union {
        box { <-3,-1,-1>, <-1,1,1> }
        box { <1,-1,-1>, <3,1,1> }
        difference {
                box { -1, 1 }
                cylinder { 2*y, -2*y, 0.8 }
        }
}

With an opaque pigment, these two pieces of code produce identical results 
and the second one is probably faster. But, if the object is (partially) 
transparent, there'll be coincident surfaces problem between the boxes. 
Also, with media, there may be a "break" where the boxes share a side.

(BTW, I was wrong suggesting that using merge instead of union could help. 
As POV doesn't bound the components separately (as it does with union), but 
uses one big bounding box instead, subdividing the object doesn't make 
sense in the first place.)


-Johannes

Post a reply to this message

Hm. Thinking about it and the example you gave,
I guess you are right, merge can't handle this case
scenario, which isn't too far fetched for the solution
I presented...

But if we make those parts slightly overlapping? I'm
not too sure about the bounding in this case, and the
evaluation of surfaces, but using CSG-difference/intersection
on some parts and adding other, untouched ones to
a merge might still be faster than cutting everything from
one big object. This might require some testing, though
I'm not in the mood to test that now. Someone else
perhaps? It seems that its not THAT important anyhow,
lets just stick to union{} for non-transparent objects
and breaking the CSG in parts then.


--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde

Post a reply to this message

Tim Nikias wrote:

> But if we make those parts slightly overlapping? 

Yes, that should work. Of course, then there'll actually be _more_ 
coincident surfaces (on the sides), but if the objects have the same 
texture (which they do have in our case) this shouldn't be a problem. And 
anyway, if the parts overlap only very slightly, it wouldn't even be 
visible.

> It seems that its not THAT important anyhow, lets just 
> stick to union{} for non-transparent objects and breaking 
> the CSG in parts then.

Yep.


-Johannes

Post a reply to this message

"LibraryMan" <mrm### [at] attnet> wrote in message
news:web.3dab2e4bb35cc47c2b597c920@news.povray.org...

> Again, the specific area the camera is trained on (exact same location &
> look_at vectors) has not really changed that much, but other objects in
the
> POV file must really be slowing everything down!  And they're not even
> visible to the camera!! AARRGH!
> Many thanks,
> MMW

Is the area the camera is looking at reflective? If it is, the not visible
parts will
have to be calculated.

Are you using photons? isosurfaces? media? They can all be quite slow,
especially
used in combination.

What I tend to do is the folloing, at the top of the file I define switches
for parts of the
scene

eg from a current scene of mine

#declare ShowGlobe=0;
#declare ShowCat=0;

then later in the scene

#if (ShowGlobe=1)
    // all the code for the globe
#end

#if (ShowCat=1)
  // all the code for the cat
#end

This makes it very easy to turn parts of the scene off which gets
very important when render time for the entire scene > 20hr.

If you want more specific help, you'll have to post your code.
Don't worry about the messiness, we've all been there.

Gail
--
#macro G(H,S)disc{0z.4pigment{onion color_map{[0rgb<sin(H/pi)cos(S/pi)*(H<6)
cos(S/pi)*(H>6)>*18][.4rgb 0]}}translate<H-5S-3,9>}#end G(3,5)G(2,5.5)G(1,5)
G(.6,4)G(.5,3)G(.6,2)G(1,1)G(2,.5)G(3,.7)G(3.2,1.6)G(3.1,2.5)G(2.2,2.5)G(9,5
)G(8,5.5)G(7,5)G(7,4)G(7.7,3.3)G(8.3,2.7)G(9,2)G(9,1)G(8,.5)G(7,1)///GS

Post a reply to this message