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

As I replied to Bob Hughes, the stats in both the unioned version and
the diff'd version indicated that the scene contained 2 objects, which
mystified me, until I realized it was probably referring to the one
declared object, which I placed *2* instances of side-by-side in the
scene, like so:

[ #declare inter_arc = union { etc. ... } ]

object { inter_arc }  //which is 1.6 units wide
object { inter_arc translate x*1.6 }

I discovered that my default bounding threshold was 3, so I lowered it
to 2 for the sake of the experiment, and this DID improve the rendering
time of both versions SLIGHTLY, but the diff'd version still rendered a
little faster than the unioned version, which as stated in my original
posting, I thought was counter-intuitive.

I suppose I may not be the first ever person who ends up completely
re-writing his scene, once he learns more SDL...

Should I end up posting the code I'm talking about? Maybe someone else's
mileage will vary.  Yeah, what the hey!

---Mark


Mike Williams wrote:
> 
> 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

I'm trying to use your macro(s), but I keep getting "bad operands for
period operator" messages.

I thought I was invoking them correctly, as in either :
Beveled_Box(0.16,0.08,0.244)

or 

Cut_Box(0.16,0.08,0.244)

What am I doing wrong?

--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

Oops, figured it out -- I'm supposed to put vectors in as C1 and C2, and
a float value for DEPTH.  
So then it renders (i.e., spawns a display window) but there is still
nothing there but darkness.  Don't I put my texture statement just
before the last '}' of the macro declaration?

???
sorry, just trying to learn something...
--LM

LibraryMan wrote:
> 
> I'm trying to use your macro(s), but I keep getting "bad operands for
> period operator" messages.
> 
> I thought I was invoking them correctly, as in either :
> Beveled_Box(0.16,0.08,0.244)
> 
> or
> 
> Cut_Box(0.16,0.08,0.244)
> 
> What am I doing wrong?
> 
> --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

In article <3DDE7A07.B6D66C46@att.net>, LibraryMan <mrm### [at] attnet> 
wrote:

> As I replied to Bob Hughes, the stats in both the unioned version and
> the diff'd version indicated that the scene contained 2 objects, which
> mystified me, until I realized it was probably referring to the one
> declared object, which I placed *2* instances of side-by-side in the
> scene, like so:

The number is the number of objects in the scene, and does not include 
declared objects, which would be a pretty useless statistic.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

I guess I'm confusing the def. of an object with the def. of a
primitive!  So for instance, 2 instances of a single box primitive with
way more than 2 other cylinder primitives differenced from it is still
only considered one object?  
That's the only way I can possibly understand the message about "2
objects, 0 infinite" (or however it's worded exactly)

--Mark

Christopher James Huff wrote:

> The number is the number of objects in the scene, and does not include
> declared objects, which would be a pretty useless statistic.
> 
> --
> Christopher James Huff <cja### [at] earthlinknet>
> http://home.earthlink.net/~cjameshuff/
> POV-Ray TAG: chr### [at] tagpovrayorg
> http://tag.povray.org/

Post a reply to this message

LibraryMan <mrm### [at] attnet> wrote in message
news:3DDE86F3.9FD3AFE6@att.net...

untested code:

[Beveled_Box macro here]

camera {
    location <0,0,-10>
    look_at <0,0,0>
} // end camera

light_source {
    <25,25,-25>
    color rgb 1
} // end light source

background {rgb 1}

#local Brick =
    Beveled_Box (
        <-1,-.5,-1>,
        <1,.5,1>,
        .05 ) // end Brick

object {
    Brick
    pigment {rgb 1}
    normal {granite bump_size .1}
} // end object

 -Shay

Post a reply to this message

In article <3DDEA0A1.411597A8@att.net>, LibraryMan <mrm### [at] attnet> 
wrote:

> I guess I'm confusing the def. of an object with the def. of a
> primitive!  So for instance, 2 instances of a single box primitive with
> way more than 2 other cylinder primitives differenced from it is still
> only considered one object?  

No, you are confusing a declared object with an object in the scene. Two 
objects in the scene make two objects in the scene. A declared object is 
not in the scene. CSG objects are compound objects composed of many 
other objects, a CSG object is counted as one object. (unions can be an 
exception to this in some cases)
A scene with two instances of a difference object has two objects in the 
scene. You can declare as many objects as you want, the number of 
objects in the scene won't change.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Wasn't it LibraryMan who wrote:
>As I replied to Bob Hughes, the stats in both the unioned version and
>the diff'd version indicated that the scene contained 2 objects, which
>mystified me, until I realized it was probably referring to the one
>declared object, which I placed *2* instances of side-by-side in the
>scene, like so:
>
>[ #declare inter_arc = union { etc. ... } ]
>
>object { inter_arc }  //which is 1.6 units wide
>object { inter_arc translate x*1.6 }
>
>I discovered that my default bounding threshold was 3, so I lowered it
>to 2 for the sake of the experiment, and this DID improve the rendering
>time of both versions SLIGHTLY, but the diff'd version still rendered a
>little faster than the unioned version, which as stated in my original
>posting, I thought was counter-intuitive.
>
>I suppose I may not be the first ever person who ends up completely
>re-writing his scene, once he learns more SDL...
>
>Should I end up posting the code I'm talking about? Maybe someone else's
>mileage will vary.  Yeah, what the hey!

Right, I've now looked at your code, and the significant factor is that
BOTH your inter_arc objects contain a difference operation that clobbers
the bounding. I suggest that you go back to my hole tutorial page and
read it more carefully this time. Then try the following:-

1. Make sure that automatic bounding is happening, and then render both
versions with the bounding slabs displayed ( use the +UD switch).
Observe that there's a single slab for the whole of the object.

2. From the first inter_arc, comment out the "difference {" and the
lines
        }
        cylinder { <-0.4, 0, -0.0101>, <-0.4, 0, 0.301> 1 
                texture {T_Grnt19b }}
        cylinder { <-0.4, 0, -0.0101>, <-0.4, 0, 0.301> 1 
                texture {T_Grnt19b } translate x*2.4 }
leaving just the brick wall without the arch cur outs, and render this
with +UD. Observe that each brick now has its own little bounding box,
that the number of box tests logged in the stats has reduced by a factor
of about 200, and that the thing renders very much faster.

3. Try cutting out the arch cylinders from each row of bricks. You
should be able to gain much of the bounding improvement. My code for
doing this looks like this:

#declare arch = union {
   cylinder { <-0.4, 0, -0.0101>, <-0.4, 0, 0.301> 1}
   cylinder { <-0.4, 0, -0.0101>, <-0.4, 0, 0.301> 1 translate x*2.4 }
}        

#declare inter_arc = union {
        difference {object { Row_Odd } object {arch}}
        difference {object { Row_Even } object {arch}}
        difference {object { Row_Odd translate y*0.16 } object {arch}}
        difference {object { Row_Even translate y*0.16 } object {arch}}
        difference {object { Row_Odd translate y*0.24 } object {arch}}
        difference {object { Row_Even translate y*0.24 } object {arch}}
        difference {object { Row_Odd translate y*0.32 } object {arch}}
        difference {object { Row_Even translate y*0.32 } object {arch}}
        difference {object { Row_Odd translate y*0.40 } object {arch}}
        difference {object { Row_Even translate y*0.40 } object {arch}}
        difference {object { Row_Odd translate y*0.48 } object {arch}}
        difference {object { Row_Even translate y*0.48 } object {arch}}
        difference {object { Row_Odd translate y*0.56 } object {arch}}
        difference {object { Row_Even translate y*0.56 } object {arch}}
        difference {object { Row_Odd translate y*0.64 } object {arch}}
        difference {object { Row_Even translate y*0.64 } object {arch}}
        difference {object { Row_Odd translate y*0.72 } object {arch}}
        difference {object { Row_Even translate y*0.72 } object {arch}}
        difference {object { Row_Odd translate y*0.8 } object {arch}}
        difference {object { Row_Even translate y*0.8 } object {arch}}
        difference {object { Row_Odd translate y*0.96 } object {arch}}
        difference {object { Row_Even translate y*0.96 } object {arch}}
        difference {object { Row_Odd translate y*1.04 } object {arch}}
        difference {object { Row_Odd translate y*1.04 } object {arch}}
     texture {T_Grnt19b}
}                                                                                     
          

Which only gives a 20 fold decrease in the number of box tests (because
there's only one bounding slab per row, instead of one per brick) and
results in a 5 fold speed increase.

4. for real speed (and coding simplicity) use a #while loop to place
each individual brick, and difference the arch cutouts from each brick.
That way you get a bounding slab for each brick.
You might think that there would be an overhead from performing lots of
unnecessary differences, but you're actually already telling POV to do
all those difference operations anyway, they're just buried inside the
unions.


-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Mike Williams wrote:

> 4. for real speed (and coding simplicity) use a #while loop to place
> each individual brick, 


I'll second that! The stuff you are doing is much much easier to do with 
loops. Trust me, I have done a lot of individual-brick-placing myself. 
My latest church has over 100000 objects. I couldn't have done that 
without loops.

/Ib

Post a reply to this message

Mike Williams wrote:

>  I suggest that you go back to my hole tutorial page and
> read it more carefully this time. Then try the following:-
>

Sorry -- actually the code posted was as exactly as it stood before I started
the whole thread.  I make no pretense that I've yet gotten around to visiting
your hole tutorial page. :-)
Thanks for your input! --
I will try your suggestions, and compare them to Shay's macro, once I can get
some free time to look at them both.  (I'm at work now -- gotta' work!
Perhaps as a "Gentleman of Leisure" this is a mundane consideration for you!
;-)  )



>
> 1. Make sure that automatic bounding is happening, and then render both
> versions with the bounding slabs displayed ( use the +UD switch).
> Observe that there's a single slab for the whole of the object.
>
> 2. From the first inter_arc, comment out the "difference {" and the
> lines
>         }
>         cylinder { <-0.4, 0, -0.0101>, <-0.4, 0, 0.301> 1
>                 texture {T_Grnt19b }}
>         cylinder { <-0.4, 0, -0.0101>, <-0.4, 0, 0.301> 1
>                 texture {T_Grnt19b } translate x*2.4 }
> leaving just the brick wall without the arch cur outs, and render this
> with +UD. Observe that each brick now has its own little bounding box,
> that the number of box tests logged in the stats has reduced by a factor
> of about 200, and that the thing renders very much faster.
>
> 3. Try cutting out the arch cylinders from each row of bricks. You
> should be able to gain much of the bounding improvement. My code for
> doing this looks like this:
>
> #declare arch = union {
>    cylinder { <-0.4, 0, -0.0101>, <-0.4, 0, 0.301> 1}
>    cylinder { <-0.4, 0, -0.0101>, <-0.4, 0, 0.301> 1 translate x*2.4 }
> }
>
> #declare inter_arc = union {
>         difference {object { Row_Odd } object {arch}}
>         difference {object { Row_Even } object {arch}}
>         difference {object { Row_Odd translate y*0.16 } object {arch}}
>         difference {object { Row_Even translate y*0.16 } object {arch}}
>         difference {object { Row_Odd translate y*0.24 } object {arch}}
>         difference {object { Row_Even translate y*0.24 } object {arch}}
>         difference {object { Row_Odd translate y*0.32 } object {arch}}
>         difference {object { Row_Even translate y*0.32 } object {arch}}
>         difference {object { Row_Odd translate y*0.40 } object {arch}}
>         difference {object { Row_Even translate y*0.40 } object {arch}}
>         difference {object { Row_Odd translate y*0.48 } object {arch}}
>         difference {object { Row_Even translate y*0.48 } object {arch}}
>         difference {object { Row_Odd translate y*0.56 } object {arch}}
>         difference {object { Row_Even translate y*0.56 } object {arch}}
>         difference {object { Row_Odd translate y*0.64 } object {arch}}
>         difference {object { Row_Even translate y*0.64 } object {arch}}
>         difference {object { Row_Odd translate y*0.72 } object {arch}}
>         difference {object { Row_Even translate y*0.72 } object {arch}}
>         difference {object { Row_Odd translate y*0.8 } object {arch}}
>         difference {object { Row_Even translate y*0.8 } object {arch}}
>         difference {object { Row_Odd translate y*0.96 } object {arch}}
>         difference {object { Row_Even translate y*0.96 } object {arch}}
>         difference {object { Row_Odd translate y*1.04 } object {arch}}
>         difference {object { Row_Odd translate y*1.04 } object {arch}}
>      texture {T_Grnt19b}
> }
>
> Which only gives a 20 fold decrease in the number of box tests (because
> there's only one bounding slab per row, instead of one per brick) and
> results in a 5 fold speed increase.
>
> 4. for real speed (and coding simplicity) use a #while loop to place
> each individual brick, and difference the arch cutouts from each brick.
> That way you get a bounding slab for each brick.
> You might think that there would be an overhead from performing lots of
> unnecessary differences, but you're actually already telling POV to do
> all those difference operations anyway, they're just buried inside the
> unions.
>
> --
> Mike Williams
> Gentleman of Leisure

Post a reply to this message

Oh yeah, I knew that! <:-)  (I suppose I was implicitly assuming that each
object that got declared also got "used" , at least once.)

--Mark

Christopher James Huff wrote:

>
>
> No, you are confusing a declared object with an object in the scene. Two
> objects in the scene make two objects in the scene. A declared object is
> not in the scene....
>  You can declare as many objects as you want, the number of
> objects in the scene won't change.
>
> --
> Christopher James Huff <cja### [at] earthlinknet>
> http://home.earthlink.net/~cjameshuff/
> POV-Ray TAG: chr### [at] tagpovrayorg
> http://tag.povray.org/

Post a reply to this message

I can appreciate that, but I haven't learned that much of the SDL yet, and I
have scant programming experience, anyway.
I can appreciate conceptually that a #while loop would automate the
construction and the coding quite a bit, but my 'style' of workflow on my
POV scene is that I tend to go ahead and write *some* code according to the
first 'version' of a scene element that occurs to me, with the intention of
eventually substituting more efficient 'versions' of the elements as I learn
more SDL.

I just haven't gotten to these macros and loops yet.  In time.... ;-)  I
also spend/waste a fair bit of time downloading trial modelling apps,
usually ending up puzzling over the docs and the interface before I
determime that I don't know how to make it do what I have in my
cobweb-filled head!

--Mark

Ib Rasmussen wrote:

> Mike Williams wrote:
>
> > 4. for real speed (and coding simplicity) use a #while loop to place
> > each individual brick,
>
> I'll second that! The stuff you are doing is much much easier to do with
> loops. Trust me, I have done a lot of individual-brick-placing myself.
> My latest church has over 100000 objects. I couldn't have done that
> without loops.
>
> /Ib

Post a reply to this message

Thanks for your link to the tutorial.  Having applied its principles (as
particularly spelled out in your most recent posting on this thread) I
have been going through my scene files with a fine-tooth comb, and have
found a couple of elements/objects which benefitted greatly -- and
others for which my initial versions were slightly superior. ;-)  

Going "back to the drawing board" is sometimes a bit of a bother, but
always a learning experience.
Many thanks again!
--Mark

Mike Williams wrote:
> 
> Wasn't it LibraryMan who wrote:
> >As I replied to Bob Hughes, the stats in both the unioned version and
> >the diff'd version indicated that the scene contained 2 objects, which
> >mystified me, until I realized it was probably referring to the one
> >declared object, which I placed *2* instances of side-by-side in the
> >scene, like so:
> >
> >[ #declare inter_arc = union { etc. ... } ]
> >
> >object { inter_arc }  //which is 1.6 units wide
> >object { inter_arc translate x*1.6 }
> >
> >I discovered that my default bounding threshold was 3, so I lowered it
> >to 2 for the sake of the experiment, and this DID improve the rendering
> >time of both versions SLIGHTLY, but the diff'd version still rendered a
> >little faster than the unioned version, which as stated in my original
> >posting, I thought was counter-intuitive.
> >
> >I suppose I may not be the first ever person who ends up completely
> >re-writing his scene, once he learns more SDL...
> >
> >Should I end up posting the code I'm talking about? Maybe someone else's
> >mileage will vary.  Yeah, what the hey!
> 
> Right, I've now looked at your code, and the significant factor is that
> BOTH your inter_arc objects contain a difference operation that clobbers
> the bounding. I suggest that you go back to my hole tutorial page and
> read it more carefully this time. Then try the following:-
> 
> 1. Make sure that automatic bounding is happening, and then render both
> versions with the bounding slabs displayed ( use the +UD switch).
> Observe that there's a single slab for the whole of the object.
> 
> 2. From the first inter_arc, comment out the "difference {" and the
> lines
>         }
>         cylinder { <-0.4, 0, -0.0101>, <-0.4, 0, 0.301> 1
>                 texture {T_Grnt19b }}
>         cylinder { <-0.4, 0, -0.0101>, <-0.4, 0, 0.301> 1
>                 texture {T_Grnt19b } translate x*2.4 }
> leaving just the brick wall without the arch cur outs, and render this
> with +UD. Observe that each brick now has its own little bounding box,
> that the number of box tests logged in the stats has reduced by a factor
> of about 200, and that the thing renders very much faster.
> 
> 3. Try cutting out the arch cylinders from each row of bricks. You
> should be able to gain much of the bounding improvement. My code for
> doing this looks like this:
> 
> #declare arch = union {
>    cylinder { <-0.4, 0, -0.0101>, <-0.4, 0, 0.301> 1}
>    cylinder { <-0.4, 0, -0.0101>, <-0.4, 0, 0.301> 1 translate x*2.4 }
> }
> 
> #declare inter_arc = union {
>         difference {object { Row_Odd } object {arch}}
>         difference {object { Row_Even } object {arch}}
>         difference {object { Row_Odd translate y*0.16 } object {arch}}
>         difference {object { Row_Even translate y*0.16 } object {arch}}
>         difference {object { Row_Odd translate y*0.24 } object {arch}}
>         difference {object { Row_Even translate y*0.24 } object {arch}}
>         difference {object { Row_Odd translate y*0.32 } object {arch}}
>         difference {object { Row_Even translate y*0.32 } object {arch}}
>         difference {object { Row_Odd translate y*0.40 } object {arch}}
>         difference {object { Row_Even translate y*0.40 } object {arch}}
>         difference {object { Row_Odd translate y*0.48 } object {arch}}
>         difference {object { Row_Even translate y*0.48 } object {arch}}
>         difference {object { Row_Odd translate y*0.56 } object {arch}}
>         difference {object { Row_Even translate y*0.56 } object {arch}}
>         difference {object { Row_Odd translate y*0.64 } object {arch}}
>         difference {object { Row_Even translate y*0.64 } object {arch}}
>         difference {object { Row_Odd translate y*0.72 } object {arch}}
>         difference {object { Row_Even translate y*0.72 } object {arch}}
>         difference {object { Row_Odd translate y*0.8 } object {arch}}
>         difference {object { Row_Even translate y*0.8 } object {arch}}
>         difference {object { Row_Odd translate y*0.96 } object {arch}}
>         difference {object { Row_Even translate y*0.96 } object {arch}}
>         difference {object { Row_Odd translate y*1.04 } object {arch}}
>         difference {object { Row_Odd translate y*1.04 } object {arch}}
>      texture {T_Grnt19b}
> }
> 
> Which only gives a 20 fold decrease in the number of box tests (because
> there's only one bounding slab per row, instead of one per brick) and
> results in a 5 fold speed increase.
> 
> 4. for real speed (and coding simplicity) use a #while loop to place
> each individual brick, and difference the arch cutouts from each brick.
> That way you get a bounding slab for each brick.
> You might think that there would be an overhead from performing lots of
> unnecessary differences, but you're actually already telling POV to do
> all those difference operations anyway, they're just buried inside the
> unions.
> 
> --
> Mike Williams
> Gentleman of Leisure

Post a reply to this message