I have an object which I created two versions of, which look quite
similar.  I had read somewhere on this group that in general, CSG
difference takes more time to trace than union.  But when I rendered the
two "versions" of the object in question ( a section of arcade from yet
another Gothic cathedral scene) the version with lots of difference's 
rendered faster than the version that was all unioning and translating.

To clarify:
Version 1 was a single large box object with a stone texture, and lots
of long narrow cylinders differenced from the visible surface to
simulate the look of the wall being built from individual blocks of
stone, like so:

_________________
|___|___|___|___
__|___|___|___|__
|___|___|___|___
__|___|___|___|__
|___|___|___|___   etc.

Version two was built from iterations of the actual individual block of
stone, translated to achieve the "staggered" look. 

Why might this have happened? It seems contrary to my initial assumption
(which admittedly might have been in error...)

Any thoughts?

Thanks,
"Library Man"

Post a reply to this message

BTW, I included a certain amount of "offset" in my translating, like the
example of the tiled surface in the section of doc about
superquadric-ellipsoids...
--LibraryMan

LibraryMan wrote:
> 
> I have an object which I created two versions of, which look quite
> similar.  I had read somewhere on this group that in general, CSG
> difference takes more time to trace than union.  But when I rendered the
> two "versions" of the object in question ( a section of arcade from yet
> another Gothic cathedral scene) the version with lots of difference's
> rendered faster than the version that was all unioning and translating.
> 
> To clarify:
> Version 1 was a single large box object with a stone texture, and lots
> of long narrow cylinders differenced from the visible surface to
> simulate the look of the wall being built from individual blocks of
> stone, like so:
> 
> _________________
> |___|___|___|___
> __|___|___|___|__
> |___|___|___|___
> __|___|___|___|__
> |___|___|___|___   etc.
> 
> Version two was built from iterations of the actual individual block of
> stone, translated to achieve the "staggered" look.
> 
> Why might this have happened? It seems contrary to my initial assumption
> (which admittedly might have been in error...)
> 
> Any thoughts?
> 
> Thanks,
> "Library Man"

Post a reply to this message

"LibraryMan" <mrm### [at] attnet> wrote in message
news:3DDD4043.CD432E69@att.net...
> the version with lots of difference's
> rendered faster than the version that was all unioning and translating.
> Version 1 was a single large box object with a stone texture, and lots
> of long narrow cylinders differenced from the visible surface to
> simulate the look of the wall being built from individual blocks of
> stone
> Version two was built from iterations of the actual individual block of
> stone, translated to achieve the "staggered" look.
>
> Why might this have happened? It seems contrary to my initial assumption
> (which admittedly might have been in error...)

Probably due most to number of visible objects and gaps inbetween. I think
the differenced object might only be seen as a single bounded entity whereas
the other might be seen as a group or collection of bounded objects. But I'm
not certain of this.

Post a reply to this message

LibraryMan <mrm### [at] attnet> wrote in message
news:3DDD43DB.42D64DB8@att.net...

Did the staggered objects use difference? This would have meant more
difference in the final wall, not less.

 -Shay

Post a reply to this message

No.  There was no difference operation anywhere in the code that
described that *version* of the object.

You know how the mortar between bricks or stones in a wall has a kind of
concave look to it? (i.e., it doesn't usually bleed out, like too much
peanut butter oozing out the side of a sandwich -- at least not on a
wall built by a mason who knows what s/he's doing)  For the other
version of my object, I differenced the cylinders so that their central
axes ran parallel to the vertical surface of a box object.  The radii of
these cylinders are greater than the distance by which they "cut" into
the wall surface.  I had the cylinders running both horizontally and
vertically, the total visual effect being like the diagram I drew.

Clear?
--Mark

P.S.  I considered using one big box with a modified version of the
irregular bricks pattern in textures.inc, but I'm not versed in using
macros yet...


Shay wrote:
> 
> LibraryMan <mrm### [at] attnet> wrote in message
> news:3DDD43DB.42D64DB8@att.net...
> 
> Did the staggered objects use difference? This would have meant more
> difference in the final wall, not less.
> 
>  -Shay

Post a reply to this message

Ahh, good point.  The messages I receive from both versions say that
there are 2 objects in the scene, but my bounding threshold is set for
3.  Perhaps if I lower the bounding threshold, more efficient bounding
will kick in?

--Library Man



"hughes, b." wrote:
> 
> "LibraryMan" <mrm### [at] attnet> wrote in message
> news:3DDD4043.CD432E69@att.net...
> > the version with lots of difference's
> > rendered faster than the version that was all unioning and translating.
> > Version 1 was a single large box object with a stone texture, and lots
> > of long narrow cylinders differenced from the visible surface to
> > simulate the look of the wall being built from individual blocks of
> > stone
> > Version two was built from iterations of the actual individual block of
> > stone, translated to achieve the "staggered" look.
> >
> > Why might this have happened? It seems contrary to my initial assumption
> > (which admittedly might have been in error...)
> 
> Probably due most to number of visible objects and gaps inbetween. I think
> the differenced object might only be seen as a single bounded entity whereas
> the other might be seen as a group or collection of bounded objects. But I'm
> not certain of this.

Post a reply to this message

"LibraryMan" <mrm### [at] attnet> wrote in message
news:3DDD6D3D.914C538D@att.net...
> Ahh, good point.  The messages I receive from both versions say that
> there are 2 objects in the scene, but my bounding threshold is set for
> 3.  Perhaps if I lower the bounding threshold, more efficient bounding
> will kick in?

Only way to be sure is to try it I guess. I had to look to be sure but mine
is set to only 1. Well, if you think about it, if it is set so low then you
are forcing automatic bounding on for practically every scene you make. You
might want to use -mb and +mb instead to turn it off and on. I think I ended
up leaving mine so low by mistake while checking something.

The default of +mb is 25 (had to look it up) and I see the doc tells only 5
might be better, probably for such low object count scenes but I'm not sure
about that. I think you'll need to test each individual scene for any
change.

Post a reply to this message

LibraryMan <mrm### [at] attnet> wrote in message
news:3DDD4043.CD432E69@att.net...

The best answer I think would be to scrap the whole thing and use mesh
bricks. Here's a link to a beveled mesh box macro which I posted some time
ago:
http://news.povray.org/povray.binaries.scene-files/21587/
I would suggest either having the bricks touch or putting a plane on the
mortar level to speed up rendering even more. You could also edit this macro
to only put bevels where they will be visible.

 -Shay

Post a reply to this message

Could be a possibility, thanks.
Once I read enough of the docs to learn how to use macros, I'll be able
to see what it does!  (I usually lurk in povray.newusers -- and I tried
copying and pasting your macro into a generic test file, but since I had
not assigned a pigment or a texture, and don't know where to do so, I
saw nothing but blackness...)

--LibraryMan

Shay wrote:
> 
> LibraryMan <mrm### [at] attnet> wrote in message
> news:3DDD4043.CD432E69@att.net...
> 
> The best answer I think would be to scrap the whole thing and use mesh
> bricks. Here's a link to a beveled mesh box macro which I posted some time
> ago:
> http://news.povray.org/povray.binaries.scene-files/21587/
> I would suggest either having the bricks touch or putting a plane on the
> mortar level to speed up rendering even more. You could also edit this macro
> to only put bevels where they will be visible.
> 
>  -Shay

Post a reply to this message

Wasn't it LibraryMan who wrote:
>I have an object which I created two versions of, which look quite
>similar.  I had read somewhere on this group that in general, CSG
>difference takes more time to trace than union.  But when I rendered the
>two "versions" of the object in question ( a section of arcade from yet
>another Gothic cathedral scene) the version with lots of difference's 
>rendered faster than the version that was all unioning and translating.

The problem with multiple differences is that POV can only set a single
bounding slab for the whole thing. If you've got one big object with
lots of little bits cut out of it, then POV ends up having to test every
one of the CSG components for every ray. (See the "hole tutorial" at 
<http://www.econym.demon.co.uk/holetut/>). Whereas, for a union, POV can
usually create a sensible hierarchy of bounding slabs, and only tests a
small number of slabs and CSG components for each ray.

Perhaps you somehow managed to end up with sensible bounding in the
differenced object, or with very poor bounding in the unioned object. It
should be quite obvious from the stats if either of these is the case. 

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message