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