 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Is there some built-in POV feature that would help me diagnose which
elements of a scene are hogging all the render time? I'm trying to
temporarily focus the camera on a small corner of my scene, which as far as
I can tell, is composed only of CSG's that I didn't think were all that
elaborate (after, _I_ coded them, and I don't know jack about macros yet).
But the problem is that the render times seem disproportionately long.
I've exchanged all the area_lights for simple, normal light statements, and
commented out the sky_sphere, but something still is really slowing down
the works. I would EXPECT a longer render if I was trying to do the whole
scene, but GEEZ!
I suppose this complaint is not too informative without my code, but I don't
think
1) anyone really wants to mess with THAT ;-)
2) I would care to reveal what an inefficient coder I really am... ;-)
So let's keep it to generalities, shall we?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"LibraryMan" <mrm### [at] att net> wrote in message
news: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?
Probably the easiest way is to use histogram output. Commenting out
individual parts of your scenes can get difficult if they are large or
complex.
Idea of the histogram image output is to look for lighter areas (of a
bitmap) which are where the most computation is taking place. Of course that
means you'll need to know what's where beforehand to campare unless it shows
readily enough. That's because sometimes the histogram can look rather
different from the regular render.
To use it, example here, put in the command line:
+W320 +H240 +HTS +HS32.24 +HNhisto.bmp
That will create a bitmap (PC's will make a BMP) named "histo" in the same
place as the POV file with block sizes of 1/10 the original image
resolution.
For info on all this do a search for histogram in the Doc. It's section
5.2.2.4.
--
Farewell,
Bob
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Sorry, please let me rephrase what I said last time.
I just tried a histogram again myself and I was thinking wrong about the way
the resolution is done. I seldom ever use that feature, great as it may be.
In fact, having reread the Doc on histogram it seems to suggest only PNG
image format works as I was thinking, not bmp or others. Not really sure.
Shows how little I've used it.
Anyway, since I'm back I should point out the fact that noise might get
introduced from slowdowns caused outside of POV-Ray, such as multi-tasking.
So don't rely on 1:1 ratio histograms to be exact, that's where using a
block of pixels can be better for averaging it out I guess.
--
Farewell,
Bob
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:web.3dab05c494823da42b597c920@news.povray.org LibraryMan wrote:
> Is there some built-in POV feature that would help me diagnose which
> elements of a scene are hogging all the render time?
> [...]
> So let's keep it to generalities, shall we?
After a rendering POV-Ray generates some statistics; Ray-Shape
intersection etc. These can give you a clue what is taking up the time.
Ingo
p.s. If somebody can, and is willing to, write a tutorial on the proper
use and interpretation of these statistics and the histogram I would like
to put it in the docs.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
So in order to quicken things up, you might want to break
the CSG into smaller parts.
Example:
A box with a cylinder cut out of it.
Suggestion:
Divide the box into several boxes, making on difference on
one small box which just about fits the cylinder, and leave the
others ontouched and set to fill the remaining space of the
original box.
Depending on your CSG, this might get quite complicated,
but its sometimes worth the effort. Also, only use merge{} if
actual need for transparent objects is there.
A friend of mine constructed a castle once using merge, thus,
the entire castle used one bounding box, and it seemed as if
POV-Ray tested every brick of the castle for every ray. Using
union speed up the tracing process by at least 60% (pending on
the amount of space the castle filled in the final image of course).
That general enough? :-)
Regards,
Tim
--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde
> Is there some built-in POV feature that would help me diagnose which
> elements of a scene are hogging all the render time? I'm trying to
> temporarily focus the camera on a small corner of my scene, which as far
as
> I can tell, is composed only of CSG's that I didn't think were all that
> elaborate (after, _I_ coded them, and I don't know jack about macros yet).
> But the problem is that the render times seem disproportionately long.
>
> I've exchanged all the area_lights for simple, normal light statements,
and
> commented out the sky_sphere, but something still is really slowing down
> the works. I would EXPECT a longer render if I was trying to do the whole
> scene, but GEEZ!
>
> I suppose this complaint is not too informative without my code, but I
don't
> think
> 1) anyone really wants to mess with THAT ;-)
> 2) I would care to reveal what an inefficient coder I really am... ;-)
>
> So let's keep it to generalities, shall we?
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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)
"Hear, hear!" re: your call for a comprehensible section of documentation on
interpreting these!!
Thanks!
--Mark
----------------------------------------------------------------------------
Ray->Shape Intersection Tests Succeeded Percentage
----------------------------------------------------------------------------
Bicubic Patch 1897457 0 0.00
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
Bounding Box 271143478 269643947 99.45
Vista Buffer 354626132 284448051 80.21
----------------------------------------------------------------------------
Roots tested: 151485 eliminated: 0
Calls to Noise: 9269544 Calls to DNoise: 9200914
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Smallest Alloc: 25 bytes Largest: 63088
Peak memory used: 66393421 bytes
----------------------------------------------------------------------------
Time For Parse: 0 hours 0 minutes 49.0 seconds (49 seconds)
Time For Trace: 0 hours 59 minutes 10.0 seconds (3496 seconds)
Total Time: 0 hours 59 minutes 5.0 seconds (3545 seconds)
POV-Ray finished
Post a reply to this message
|
|
| |
| |
|
|
From: Johannes Dahlstrom
Subject: Re: Something holding up the works...
Date: 14 Oct 2002 16:28:50
Message: <3dab2902@news.povray.org>
|
|
|
| |
| |
|
|
Tim Nikias wrote:
> So in order to quicken things up, you might want to break
> the CSG into smaller parts.
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
|
|
| |
| |
|
|
From: Johannes Dahlstrom
Subject: Re: Something holding up the works...
Date: 14 Oct 2002 16:48:34
Message: <3dab2da1@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
