 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've only come up with limited information on what the final statistics
shown after a render really mean. Am I missing an obvious portion of the
documentation? I have found a few previous messages posted in regards to
this, yet I am still a bit puzzled.
After an eighteen-hour render of my image at 320x240 resolution, I am
interested in trying to determine where my inefficiency lies. My scene is
mostly full of cylinders... along with a small object made of
smooth_triangles that happens to be copied... er, a lot. I suspect this
could be the error of my ways, and perhaps I should replace them with some
more efficient primitives. However, I thought I was being responsible by
placing my triangles inside a union, and then simply referring to this
object repeatedly. Have I misunderstood previous discussions about
efficient triangle mesh handling?
I thought, perhaps, I could use the histogram output option to determine
where my image was slowing down. Unfortunately, the only information I
really got from the histogram was that the glass objects in my scene take
more time to render than the other objects. Alas, by removing the glass
objects, I do not see a huge increase of speed (as one might expect from
having a scene full of only cylinders... er, and some of those
aforementioned pesky smooth_triangles).
So, would someone be so kind as to give me a thorough explanation of my
statistics (as follow), or else point me to the right location so I might
read up on what they mean? Not a usual exciting question for the group, but
I'm at a loss of where to go to learn this. Blush.
Here's what I see:
Statistics for experimental_setup3.pov, Resolution 320 x 240
----------------------------------------------------------------------------
Pixels: 77120 Samples: 693400 Smpls/Pxl: 8.99
Rays: 719773 Saved: 3052 Max Level: 6/10
----------------------------------------------------------------------------
Ray->Shape Intersection Tests Succeeded Percentage
----------------------------------------------------------------------------
Box 407629001 9601576 2.36
Cone/Cylinder 1302284200 9226351 0.71
CSG Intersection 208771746 4865007 2.33
CSG Merge 919798 256294 27.86
CSG Union 3239336206 8895934 0.27
Plane 11367768 675690 5.94
Sphere 7357978 17042 0.23
Torus 294219586 1801162 0.61
Torus Bound 294219586 2160324 0.73
Triangle 157988919600 148549 0.00
Bounding Box 187611431 69542575 37.07
Light Buffer 8242761 3898242 47.29
Vista Buffer 5779806 4141312 71.65
----------------------------------------------------------------------------
Roots tested: 2160324 eliminated: 1003830
Calls to Noise: 23584421 Calls to DNoise: 24259518
----------------------------------------------------------------------------
Shadow Ray Tests: 23171879 Succeeded: 2160378
Reflected Rays: 14639 Total Internal: 208
Refracted Rays: 11734
----------------------------------------------------------------------------
Smallest Alloc: 25 bytes Largest: 24600
Peak memory used: 39956520 bytes
----------------------------------------------------------------------------
Time For Parse: 0 hours 0 minutes 1.0 seconds (1 seconds)
Time For Trace: 15 hours 8 minutes 27.0 seconds (54503 seconds)
Total Time: 15 hours 8 minutes 24.0 seconds (54504 seconds)
----------------------------------------------------------------------------
CPU time used: kernel 1.77 seconds, user 50408.08 seconds, total 50409.84
seconds
Render averaged 1.52 PPS over 76800 pixels
Alright, now, I understand what the first section seems to be telling me,
except for the 'Saved' value. Are we referring to saved rays? What did I
save them from doing?
Forgive me for being dense, but in the second section I see that some shapes
have much lower percentages than others. This is a ... Bad Thing? I
naively envision my scene only testing (and succeeding with) rays it really
'needs' to calculate, so the better the percentages, the fewer 'wasted' rays
were used? Thus, the better the percentages, the more efficient my scene
is? If this is true, then I appear to be horribly inefficient with my
Triangles.
The third category is even more puzzling. Is this simply for my
information, or can I somehow glean useful knowledge about whether my
objects are calling Noise vs. DNoise, and which should be a better thing.
The docs only mention DNoise in one place (6.7.12.6.4) and from my reading,
it's not that DNoise is any better/worse than Noise calls... just different.
Does the fact that DNoise returns a direction instead of just a value
somehow indicate that those calls were slower? Perhaps they really are
shown just for my information.
The fourth section seems to make more sense to me. If I have a lot of
reflected/refracted rays, my scene will take longer to render. What about
shadow ray tests vs. success? Again, just information, or can I use this to
my advantage?
I'm also puzzled by the Smallest and Largest memory allocation (the next
section). Er, call me obtuse, but if my largest memory allocation is 24KB,
how can my peak memory used be 40MB? Obviously I am woefully
misinterpreting these values. Blush.
Well, at least I understand the last few lines - I know it takes me a really
long time to render a scene that (I think) should be relatively simple.
Anyone care to take a stab at enlightening me? I would greatly appreciate
it.
- How
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Forgive me for being dense, but in the second section I see that some
shapes
> have much lower percentages than others. This is a ... Bad Thing? I
> naively envision my scene only testing (and succeeding with) rays it
really
> 'needs' to calculate, so the better the percentages, the fewer 'wasted'
rays
> were used? Thus, the better the percentages, the more efficient my scene
> is? If this is true, then I appear to be horribly inefficient with my
> Triangles.
That caught my eye too. I don't look at statistics often, so those may be
typical percentages, but I dunno, they seem awfully low. Maybe you're doing
something that makes bounding boxes inefficient?
> The third category is even more puzzling.
To determine if Noise is the cause of your slowdown, try rendering with
textures turned off (I believe there's a command line option that does this
easily; +Q? Search the docs for "quality"). I wouldn't worry about this too
much though.
> The fourth section seems to make more sense to me. If I have a lot of
> reflected/refracted rays, my scene will take longer to render.
You don't seem to have to many - and you said that taking out the glass
objects doesn't fix things anyway.
> What about
> shadow ray tests vs. success? Again, just information, or can I use this
to
> my advantage?
Doesn't seem *that* bad, but shadow ray tests go in hand with what I said
about the other percentages.
> I'm also puzzled by the Smallest and Largest memory allocation (the next
> section). Er, call me obtuse, but if my largest memory allocation is
24KB,
> how can my peak memory used be 40MB?
There can be (and usually are) multiple allocations as the program runs; the
sum of all of these allocations was 40MB. (Er, more precisely, 40MB was the
most allocated at any time, but it was made up of multiple smaller
allocations.)
So, anyway, the thing that worries me the most is the ray intersection
percentages. Are you using lots of intersections/differences, maybe? That,
among other things, can cause bounding boxes to be so large that they don't
help at all.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it How Camp who wrote:
>I've only come up with limited information on what the final statistics
>shown after a render really mean. Am I missing an obvious portion of the
>documentation? I have found a few previous messages posted in regards to
>this, yet I am still a bit puzzled.
>Ray->Shape Intersection Tests Succeeded Percentage
>----------------------------------------------------------------------------
>Triangle 157988919600 148549 0.00
>----------------------------------------------------------------------------
This line suggests to me that you're getting extremely bad bounds for
your triangle objects. Since there are 719773 rays, on average each ray
is being tested to see if it intersects 219498 but on average it only
hits 0.2 of them.
The fact that the rays miss most of the triangles suggests that the
triangles are very small, but the fact that many tests are being
performed suggests that the bounds are very large.
Could you possibly be doing something that prevents POV from
automatically bounding them efficiently, such as using them in a large
CSG intersection?
If you've still got the copy of the scene without the glass cylinders
you can get an idea of what the bounding slabs look like by running with
+UD on the command line. What you should be hoping to see is lots of
tight little boxes fitted around each of the small objects, and what you
don't want to see is one big box loosely fitted around the whole
structure.
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
How Camp wrote:
> [...]
>
> Forgive me for being dense, but in the second section I see that some shapes
> have much lower percentages than others. This is a ... Bad Thing? I
> naively envision my scene only testing (and succeeding with) rays it really
> 'needs' to calculate, so the better the percentages, the fewer 'wasted' rays
> were used? Thus, the better the percentages, the more efficient my scene
> is? If this is true, then I appear to be horribly inefficient with my
> Triangles.
This part of the statistics should be pretty self-explanatory if you
know how a raytracer works. It tells you how many intersection tests
are done for each type of shape and how many of them hit the object.
Therefore a 'simple higher percentage = better' is of course not true
but a very low percentage indicates problems. You are horribly
inefficient with the triangles, the reason probably being you did not
use a mesh (no mesh is listed in your statistics).
> The third category is even more puzzling. Is this simply for my
> information, or can I somehow glean useful knowledge about whether my
> objects are calling Noise vs. DNoise, and which should be a better thing.
> [...]
>
The noise/dnoise calls are the number of calls to the basic functions of
procedural patterns. These numbers will be high when you use
complicated procedural textures or isosurfaces with noise based functions.
> The fourth section seems to make more sense to me. If I have a lot of
> reflected/refracted rays, my scene will take longer to render. What about
> shadow ray tests vs. success? Again, just information, or can I use this to
> my advantage?
The shadow ray stats are a bit like the shape stats above. If most of
the visible scene is in shadow (in respect to the used light sources)
most shadow ray tests will be successful. When you use area lights high
numbers also indicate they are taking a lot of time.
> I'm also puzzled by the Smallest and Largest memory allocation (the next
> section). Er, call me obtuse, but if my largest memory allocation is 24KB,
> how can my peak memory used be 40MB? Obviously I am woefully
> misinterpreting these values. Blush.
24k is the largest unit of memory allocated as a single piece. The
total amount of memory used by the scene is ~40 MB.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 07 Mar. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Like Christoph said, I believe that the problem comes from the fact
that you put your triangles in unions instead of meshes. Povray is able
to do a lot of optimizations on meshes that it can't do on unions, so if
you only have triangles, you're always much better off with meshes (of
course, if you have other objects in the union, you can always group
first your tringles in a mesh and then the other object in the union).
Jerome
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFAWJpFqIYJdJhyixIRAsYWAJ9ZVAQ3N/ZjZp/1L70270Gk5hPS/ACfRXSg
uXz33xuor89OM0o8FUHTte8=
=T5XR
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 17 Mar 2004 02:00:27 -0500, "Slime" <fak### [at] email address>
wrote:
>
>That caught my eye too. I don't look at statistics often, so those may be
>typical percentages, but I dunno, they seem awfully low. Maybe you're doing
>something that makes bounding boxes inefficient?
>
> ...
>
>So, anyway, the thing that worries me the most is the ray intersection
>percentages. Are you using lots of intersections/differences, maybe? That,
>among other things, can cause bounding boxes to be so large that they don't
>help at all.
Yep - as you and others pointed out, I rather screwed this up. So,
then, perhaps (well, er, obviously) I don't understand how bounding
boxes work:
Let's say I have two long cylinders perpendicular to one another - a
'+' shape of some sort.
Separately, the bounding boxes would be tight around each cylinder.
If I place them in a union together, I've got one large bounding box,
which I suppose could be less efficient than two tight bounding boxes
done separately. Er, am I right so far?
Now, how do I manually make my bounding boxes any better than a single
box surrounding my odd-shaped CSG? I always (incorrectly?) pictured a
large CSG bounding box to be the 'initial' test. If a ray hits it,
then all the individual bounding boxes inside the CSG would be
checked.
Can I 'turn off' my CSG bounding box, and just let the multiple (yet
tight) boxes suffice?
- How
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 17 Mar 2004 08:46:33 +0000, Mike Williams
<nos### [at] econymdemoncouk> wrote:
>Could you possibly be doing something that prevents POV from
>automatically bounding them efficiently, such as using them in a large
>CSG intersection?
Yep, you're absolutely right. Thanks for pointing this out. See my
questions, however, in my reply to Slime.
- How
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 17 Mar 2004 09:48:38 +0100, Christoph Hormann
<chr### [at] gmxde> wrote:
>This part of the statistics should be pretty self-explanatory if you
>know how a raytracer works. It tells you how many intersection tests
>are done for each type of shape and how many of them hit the object.
>Therefore a 'simple higher percentage = better' is of course not true
>but a very low percentage indicates problems. You are horribly
>inefficient with the triangles, the reason probably being you did not
>use a mesh (no mesh is listed in your statistics).
Ack, I screwed up. I added my triangles into a union of other objects
rather than first using a mesh. Blush.
Now, please be patient with me, Christoph, but I'm still not sure I
understand your above explanation. If the statistics are informing me
of how many intersections tests were performed, and of those how many
hit my object... then why *doesn't* that mean 'higher percentage =
better'? If 100 tests are performed inside a given bounding box, and
the bounding box perfectly matched my object in size and shape...
shouldn't I get a hit percentage of 100%?
You mention that low percentages indicate potential problems. Er, how
low is 'too low'? I realize there isn't a simple answer to this, but
is there a broad rule-of-thumb I could use to help me start paying
better attention?
- How
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
<jbe### [at] ifrancecom> wrote:
> Like Christoph said, I believe that the problem comes from the fact
>that you put your triangles in unions instead of meshes. Povray is able
>to do a lot of optimizations on meshes that it can't do on unions, so if
>you only have triangles, you're always much better off with meshes (of
>course, if you have other objects in the union, you can always group
>first your tringles in a mesh and then the other object in the union).
Yep, this is exactly what I did wrong. Somehow, I convinced myself
that they aaaall needed to go in the same union. Blush. Thanks,
- How
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it How Camp who wrote:
>Yep - as you and others pointed out, I rather screwed this up. So,
>then, perhaps (well, er, obviously) I don't understand how bounding
>boxes work:
>
>Let's say I have two long cylinders perpendicular to one another - a
>'+' shape of some sort.
>
>Separately, the bounding boxes would be tight around each cylinder.
>If I place them in a union together, I've got one large bounding box,
>which I suppose could be less efficient than two tight bounding boxes
>done separately. Er, am I right so far?
Not for *unions*. For unions and merges it's possible to bound
intelligently, and POV does so. It's possible to see the effect by
rendering a simple pair of crossed cylinders with the switches
+MB0 +UD
camera {location <0,0,-10> look_at <0,0,0> angle 20}
light_source {<-30, 100, -30> color rgb 1}
union {
cylinder {-x,x,0.01}
cylinder {-y,y,0.01}
pigment {rgb 1}
}
The +MB0 sets the bounding threshold to zero. POV would normally switch
bounding off on a scene with so few objects. +UD tells POV to display
the outlines of the Vista Buffers before tracing. Vista Buffers are
derived from the bounding slabs and (in most cases) give you a good 2D
representation of where the 3D bounding slabs are.
You'll see that there are two red rectangles which fit the cylinders
tightly. And you'll also see this in the stats (this is for a 320*240 no
AA rendering), showing that only a small number of cylinder tests were
performed.
------------------------------------------------------------------
Ray->Shape Intersection Tests Succeeded Percentage
------------------------------------------------------------------
Cone/Cylinder 2035 1162 57.10
If you render a scene with two separate cylinders you get exactly the
same red rectangles and exactly the same stats.
With intersections and differences, however, there can be situations
where POVs automatic bounding can't create such tight fits.
For example, see <http://www.econym.demon.co.uk/holetut/index.htm>.
A box with 1600 cylindrical holes in it took 26 minutes 25 seconds to
render, but after rewriting the scene so that POV could bound it better
it took 8 seconds.
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
