 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 17 Mar 2004 09:48:38 +0100, Christoph Hormann
<chr### [at] gmx de> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 18 Mar 2004 03:54:47 +0000, Mike Williams
<nos### [at] econymdemoncouk> wrote:
>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
Ah, I see. Thanks for the example. So, unions are able to be 'bound
intelligently'.
>
>With intersections and differences, however, there can be situations
>where POVs automatic bounding can't create such tight fits.
>
Yes, and this is where my problem lies. I've got a lot of cylinders
being differenced with other cylinders.
>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.
Aha! So, let me see if I've got this straight. I place a large
number of objects in a CSG Union, and I should see very little
difference in speed. However, if I place a large number of objects in
a CSG difference, my bounding boxes are not calculated very well, and
the render time may be quite poor.
Now, on your wonderful web page, you showed how to overcome this
problem - you broke your larger CSG difference into a bunch of small
CSG differences. As you point out, the best you can do is to have
1600 slabs, each with only a single CSG difference in them.
Thanks so much, Mike! And the rest of the responses I've recieved,
too -- this has been quite enlightening. Already, now that I've
corrected the whole 'union-of-triangles vs. mesh' fiasco, I've
decreased my render time dramatically.
I'll try applying this information as well!
- How
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
How Camp wrote:
>
> 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%?
First of all the bounding box will of course never perfectly match the
object. Therefore if you have 100% hits this usually means the object
completely fills the view in which case it would be faster not to use
bounding for this object at all.
> 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?
No, it depends on the type of object and how it is placed. Imagine for
example a torus with a very low minor radius - you will always get a low
hit rate for it.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 18 Mar 2004 09:35:50 -0800, Darren New <dne### [at] sanrrcom>
wrote:
>As the manual explains {X inverted} is object X with the inside and
>outside reversed - a "negative" X. difference{X,Y} is the same as
>intersection{X, Y inverted}. So, by itself, Y fills your entire scene,
>other than where the cylinder or whatever actually is. *That* is what
>you have to bound for efficiency. In an intersection, POV knows that it
>can bound Y inverted by X. But if X is a union that's unnecessarily big,
>it can't really tell where Y needs to get cut off. POV can't
>automatically tell that in
> intersection ( union (A,B,C), X inverted )
>X really only affects C, So if A fills your whole screen, and X really
>only chops part of C out, rays hitting A still have to check against X.
Yes, I see it, now. So, using your example above:
intersection( union(A, B, C), X inverted)
How would I optimize the bounding boxes in this situation? The
problem lies with X's bounding box, and I need to shrink it down
considerably. Right?
>Maybe that helps? Or have I explained something wrong?
I think this helps greatly. Thanks!
- How
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"How Camp" <kro### [at] hotmailcom> wrote in message
news:u5qj50tm6ptd8vcvpuih4e0mk3afpleis1@4ax.com...
> On Thu, 18 Mar 2004 09:35:50 -0800, Darren New <dne### [at] sanrrcom>
> > intersection ( union (A,B,C), X inverted )
> >X really only affects C, So if A fills your whole screen, and X really
> >only chops part of C out, rays hitting A still have to check against X.
>
> Yes, I see it, now. So, using your example above:
>
> intersection( union(A, B, C), X inverted)
>
> How would I optimize the bounding boxes in this situation?
If X only affects C, wouldn't the following work?
union( A, B, intersection(C, ~X) )
(Using ~ for inversion)
--
...Chambers
http://www.geocities.com/bdchambers79
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 18 Mar 2004 13:02:46 -0800, Darren New <dne### [at] sanrrcom>
wrote:
>If the cylinder X only intersects C, then you need to have
> union (A, B, intersection (C, X inverted))
>aka
> union (A, B, difference(C, X))
>
>Then POV is smart enough to know that the bounding box for
> difference(C,X)
>can't be bigger than the bounding box for C.
Got it. Thanks, all, for finally getting this into me. I'll continue
to do some tests, here, but I've already seen clear evidence of this.
- How
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 18 Mar 2004 20:48:39 -0600, How Camp <kro### [at] hotmailcom>
wrote:
>
>Got it. Thanks, all, for finally getting this into me. I'll continue
>to do some tests, here, but I've already seen clear evidence of this.
>
Well, this will come as no shock to all of you who've been so helpful
in this thread, but here's the results of all my playing around:
Statistics for experimental_setup3.pov, Resolution 320 x 240
----------------------------------------------------------------------------
Pixels: 77120 Samples: 693144 Smpls/Pxl: 8.99
Rays: 718613 Saved: 2938 Max Level: 6/10
----------------------------------------------------------------------------
Ray->Shape Intersection Tests Succeeded Percentage
----------------------------------------------------------------------------
Box 50058173 24556324 49.06
Cone/Cylinder 177506624 7692921 4.33
CSG Intersection 37497796 5027965 13.41
CSG Merge 163 4 2.45
CSG Union 99867389 5542401 5.55
Mesh 552652924 76895 0.01
Plane 25780836 1600506 6.21
Sphere 163 0 0.00
Torus 12654305 1029520 8.14
Torus Bound 12654305 1151039 9.10
Bounding Object 17790727 12361787 69.48
Bounding Box 723628698 63750693 8.81
Light Buffer 5151394 3783732 73.45
Vista Buffer 8099377 6643164 82.02
----------------------------------------------------------------------------
Roots tested: 1151039 eliminated: 788253
Calls to Noise: 23582324 Calls to DNoise: 24198190
----------------------------------------------------------------------------
Shadow Ray Tests: 24593543 Succeeded: 2870814
Reflected Rays: 14186 Total Internal: 206
Refracted Rays: 11283
----------------------------------------------------------------------------
Radiosity samples calculated: 41753 (6.33 percent)
Radiosity samples reused: 617822
----------------------------------------------------------------------------
Smallest Alloc: 25 bytes Largest: 24600
Peak memory used: 11611887 bytes
----------------------------------------------------------------------------
Time For Parse: 0 hours 0 minutes 1.0 seconds (1 seconds)
Time For Trace: 0 hours 5 minutes 35.0 seconds (335 seconds)
Total Time: 0 hours 5 minutes 36.0 seconds (336 seconds)
----------------------------------------------------------------------------
CPU time used: kernel 0.80 seconds, user 279.72 seconds, total 280.52
seconds
Render averaged 273.78 PPS over 76800 pixels
Quite a bit better than 18hrs! Thanks, again.
- How
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 20 Mar 2004 15:12:37 -0800, Darren New <dne### [at] sanrrcom>
wrote:
>
>Congrats! So post the image, already! ;-)
>
Hehe, well it's not terribly exciting... unless you're really really
interested in charge-transfer collisions. Let me get the exciting
part finished, and I'll post.
>Looks like it's still doing a bunch of compares on the mesh without
>hitting it. Not sure if you could easily improve that, or whether it's
>worth the effort to.
Yeah, I noticed that, too. I may rethink my use of these meshes in
the first place - they really don't add much to the scene, and the
detail is pretty much lost. I might try replacing them with some sort
of rough primitive shape and see how much of a difference it makes.
- How
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
