 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 18 Mar 2004 03:54:47 +0000, Mike Williams
<nos### [at] econym demoncouk> 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
|
|
| |
| |
|
|
|
|
| |
|
|
