 |
|
|
|
|
|
| |
| |
|
|
From: Dave Matthews
Subject: CSG difference v. Blob difference v. Negative Blob
Date: 6 Dec 2004 15:38:30
Message: <41b4c346$1@news.povray.org>
|
|
|
| |
| |
|
|
Note: this is NOT simply another question about why CSG differences are
so slow (well, it sort of is, but. . . .)
(For the benefit of those who don't know, see Mike Williams'
http://www.econym.demon.co.uk/holetut/index.htm )
As I posted in P.B.I., I "found" (I'm sure many people have beat me to
it, but I hadn't seen it before) a simple way to greatly increase
rendering speed for a general CSG difference, by simply using a "blob"
rather than a "union" to make the "holes." In addition, there seems to
be yet another (smaller) improvement, by intersecting with a blob full
of holes, rather than simply differencing with a positive
"hole-punching" blob.
For example, the scene:
//////////
#declare UnionDiff = union {
#local J = 0;
#while (J < 30)
#local I = 0;
#while (I < 30)
cylinder { <0, -10, 0>, <0, 10, 0>, 0.2 translate <I, 0, J> }
#local I = I + 0.5;
#end
#local J = J + 0.5;
#end
pigment { color rgb z }
}
difference { box <-2, -3, -2>, <32, 3, 32> pigment { color rgb x } }
UnionDiff }
camera { angle 35 location <15, 60, 15> look_at <15, 0, 15> }
light_source { <50, 200, 50> rgb 1 }
//////////
renders at about 30 pixels per second on my machine (I didn't have the
patience to render the whole scene), while
//////////
#declare BlobDiff = blob { threshold 0.25
#local J = 0;
#while (J < 30)
#local I = 0;
#while (I < 30)
cylinder { <0, -10, 0>, <0, 10, 0>, 0.2, 2 translate <I, 0, J> }
#local I = I + 0.5;
#end
#local J = J + 0.5;
#end
pigment { color rgb z }
}
difference { box <-2, -3, -2>, <32, 3, 32> pigment { color rgb x } }
BlobDiff }
camera { angle 35 location <15, 60, 15> look_at <15, 0, 15> }
light_source { <50, 200, 50> rgb 1 }
//////////
renders at about 340 pps
and
//////////
#declare BlobNegative = blob { threshold 0.25
sphere { 0, 1, 1 scale <45, 10, 45> translate <15, 0, 15> }
#local J = 0;
#while (J < 30)
#local I = 0;
#while (I < 30)
cylinder { <0, -10, 0>, <0, 10, 0>, 0.2, -2 translate <I, 0, J> }
#local I = I + 0.5;
#end
#local J = J + 0.5;
#end
pigment { color rgb z }
}
intersection { box <-2, -3, -2>, <32, 3, 32> pigment { color rgb x } }
BlobNegative }
camera { angle 35 location <15, 60, 15> look_at <15, 0, 15> }
light_source { <50, 200, 50> rgb 1 }
//////////
renders at about 380 pps.
I know why differencing with a union is so slow, but I was wondering
A) Why is differencing with a blob so much faster?
B) (Depending on the answer to A) Would it be possible to use whatever
bounding improvements cause the blob difference to be faster to improve
the CSG difference? (Since I don't know jack about programming, this is
probably a stupid question that is almost impossible to answer at a
level I could understand, but I still have to ask it.)
C) Any idea why the intersection with a blob full of holes (3rd
example) should be faster than differencing with a positive blob (2nd
example)? Or is it purely an accident of the scenes I happened to choose?
(Note that these times were with "antialias off." The differences are
much greater -- even between the two blob methods (in absolute numbers
and in proportion) when AA 0.2 is used (as you might expect, since the
antialiasing takes place around the "holes.")
Dave Matthews
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it Dave Matthews who wrote:
>
>I know why differencing with a union is so slow, but I was wondering
>
>A) Why is differencing with a blob so much faster?
>
>B) (Depending on the answer to A) Would it be possible to use whatever
>bounding improvements cause the blob difference to be faster to improve
>the CSG difference? (Since I don't know jack about programming, this is
>probably a stupid question that is almost impossible to answer at a
>level I could understand, but I still have to ask it.)
>
>C) Any idea why the intersection with a blob full of holes (3rd
>example) should be faster than differencing with a positive blob (2nd
>example)? Or is it purely an accident of the scenes I happened to choose?
You can get some clues about what's going on by using the techniques I
used on my holes tutorial. Take a look at the Rendering Statistics
produced using different techniques. Here's the stats from scenes which
produce 2001 spherical holes in a box. I used no_shadow to avoid the
calculation of shadow rays, which caused small differences in the
numbers of rays cast in the different scenes.
PURE CSG DIFFERENCE
Ray->Shape Intersection Tests Succeeded Percentage
Box 19200 8901 46.36
CSG Intersection 38400 27933 72.74
Sphere 38419200 88971 0.23
DIFFERENCE WITH POSITIVE BLOB
Ray->Shape Intersection Tests Succeeded Percentage
Blob 19200 8130 42.34
Blob Component 69771 69771 100.00
Blob Bound 1691140 324316 19.18
Box 19200 8901 46.36
CSG Intersection 19200 8835 46.02
INTERSECTION WITH NEGATIVE BLOB
Ray->Shape Intersection Tests Succeeded Percentage
Blob 19200 18056 94.04
Blob Component 88971 88971 100.00
Blob Bound 1786832 440132 24.63
Box 19200 8901 46.36
CSG Intersection 19200 8853 46.11
I rendered a small image 160*120, so there were 19200 pixels, and since
there are no shadows, there are 19200 rays. In the pure CSG scene each
of those 19200 rays are tested against one box and 2001 spheres,
resulting in over 39 million tests being calculated. No bounding tests
occur.
In the case of the blobs, what seems to be happening is that blob
bounding does take place. It looks like the blob is calculated with the
benefits that that entails, and afterwards the CSG is performed without
ordinary bounding.
(B) I guess that it would be possible for POV to be modified to use the
same sort of trick with pure CSG differences, and thereby achieve even
greater speeds in these circumstances (because CSG cylinder and sphere
tests are faster than blob tests). It might be difficult for POV to
automatically determine when to use the trick, so it might be necessary
to have some syntax for specifying when bounds should be calculated for
a subset of a CSG object before performing the overall CSG operation.
(C) On my machine, your positive and negative blob code examples ran at
exactly the same speed. Perhaps your machine happened to be doing
something else when the positive blob code was running, or perhaps you
happened to look at the PPS numbers at different stages of the render.
The Render Statistics are so similar that I can't believe that there can
have been a real effect. The difference in the stats is caused by the
fact that there's one extra large component in the negative blob which
needs to be calculated, so the negative blob should be slightly slower.
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
From: Dave Matthews
Subject: Re: CSG difference v. Blob difference v. Negative Blob
Date: 7 Dec 2004 08:53:38
Message: <41b5b5e2$1@news.povray.org>
|
|
|
| |
| |
|
|
Mike Williams wrote:
> You can get some clues about what's going on by using the techniques I
> used on my holes tutorial. Take a look at the Rendering Statistics
> produced using different techniques. Here's the stats from scenes which
> produce 2001 spherical holes in a box. I used no_shadow to avoid the
> calculation of shadow rays, which caused small differences in the
> numbers of rays cast in the different scenes.
>
> PURE CSG DIFFERENCE
>
> Ray->Shape Intersection Tests Succeeded Percentage
> Box 19200 8901 46.36
> CSG Intersection 38400 27933 72.74
> Sphere 38419200 88971 0.23
>
> DIFFERENCE WITH POSITIVE BLOB
>
> Ray->Shape Intersection Tests Succeeded Percentage
> Blob 19200 8130 42.34
> Blob Component 69771 69771 100.00
> Blob Bound 1691140 324316 19.18
> Box 19200 8901 46.36
> CSG Intersection 19200 8835 46.02
>
> INTERSECTION WITH NEGATIVE BLOB
>
> Ray->Shape Intersection Tests Succeeded Percentage
> Blob 19200 18056 94.04
> Blob Component 88971 88971 100.00
> Blob Bound 1786832 440132 24.63
> Box 19200 8901 46.36
> CSG Intersection 19200 8853 46.11
>
> I rendered a small image 160*120, so there were 19200 pixels, and since
> there are no shadows, there are 19200 rays. In the pure CSG scene each
> of those 19200 rays are tested against one box and 2001 spheres,
> resulting in over 39 million tests being calculated. No bounding tests
> occur.
>
> In the case of the blobs, what seems to be happening is that blob
> bounding does take place. It looks like the blob is calculated with the
> benefits that that entails, and afterwards the CSG is performed without
> ordinary bounding.
That makes sense. Thanks. I still have a tough time puzzling out those
stats. Guess I'll have to study up on them more.
> (B) I guess that it would be possible for POV to be modified to use the
> same sort of trick with pure CSG differences, and thereby achieve even
> greater speeds in these circumstances (because CSG cylinder and sphere
> tests are faster than blob tests). It might be difficult for POV to
> automatically determine when to use the trick, so it might be necessary
> to have some syntax for specifying when bounds should be calculated for
> a subset of a CSG object before performing the overall CSG operation.
My thinking was that it's faster to do ordinary sphere and cylinder
tests, but now that you point it out, I guess POVRay would have to know
when to think of the union as some sort of megaSphereCylinder object
(perhaps we could call it a "Blob" -- never mind), and adding yet one
more user option -- well, I don't even know half the ones we already
have. But this situation is common enough that it might be useful.
> (C) On my machine, your positive and negative blob code examples ran at
> exactly the same speed. Perhaps your machine happened to be doing
> something else when the positive blob code was running, or perhaps you
> happened to look at the PPS numbers at different stages of the render.
> The Render Statistics are so similar that I can't believe that there can
> have been a real effect. The difference in the stats is caused by the
> fact that there's one extra large component in the negative blob which
> needs to be calculated, so the negative blob should be slightly slower.
>
I would have thought so, too, but several more complicated complete
scenes, using AA and shadows and such produced some marked differences.
If I can produce a simple example, I'll post up the summary stats, and
maybe we (you) can make sense of them.
Thanks again for all your help.
BTW, I have several students (finally) whom I've gotten interested in
POVRay, and pointed them to your site, after they get the basics from
Fredrich Lohmueller's tutorial. They think yours is a fantastic
tutorial (much clearer than my explanations, as one of them said. . . .)
Those who have had, or are taking, multi-variable calculus really
appreciate your treatment of isosurfaces. (And so do I!) None are far
enough along for POVComp 2004, but, given that some have actual artistic
talent, and all of them have programming experience, they'll probably
pass me up by the end of Christmas break.
Dave Matthews
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dave Matthews <ns### [at] nospam edu> wrote:
> As I posted in P.B.I., I "found" (I'm sure many people have beat me to
> it, but I hadn't seen it before) a simple way to greatly increase
> rendering speed for a general CSG difference, by simply using a "blob"
> rather than a "union" to make the "holes." In addition, there seems to
> be yet another (smaller) improvement, by intersecting with a blob full
> of holes, rather than simply differencing with a positive
> "hole-punching" blob.
Excellent! I'd noticed that differencing spheres from blob objects was much
faster than differencing spheres from unions (something about an internal
bounding hierarchy for blobs and meshes is in the documentation, IIRC) but
I never thought to try the opposite. This is going to save me substantial
amounts of time. Thanks for pointing this trick out!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
