POV-Ray : Newsgroups : povray.general : General question about relative efficiency of CSG operations Server Time
5 Aug 2024 10:25:53 EDT (-0400)
  General question about relative efficiency of CSG operations (Message 14 to 23 of 23)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: Christopher James Huff
Subject: Re: General question about relative efficiency of CSG operations
Date: 22 Nov 2002 15:09:21
Message: <chrishuff-814C0C.15074322112002@netplex.aussie.org>
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

From: LibraryMan
Subject: Re: General question about relative efficiency of CSG operations
Date: 22 Nov 2002 16:24:54
Message: <3DDEA0A1.411597A8@att.net>
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

From: Shay
Subject: Re: General question about relative efficiency of CSG operations
Date: 22 Nov 2002 16:38:51
Message: <3ddea3eb$1@news.povray.org>
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

From: Christopher James Huff
Subject: Re: General question about relative efficiency of CSG operations
Date: 22 Nov 2002 16:48:33
Message: <chrishuff-31468B.16465422112002@netplex.aussie.org>
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

From: Mike Williams
Subject: Re: General question about relative efficiency of CSG operations
Date: 23 Nov 2002 05:54:45
Message: <Fuo2EHA04139Ewn8@econym.demon.co.uk>
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

From: Ib Rasmussen
Subject: Re: General question about relative efficiency of CSG operations
Date: 23 Nov 2002 07:17:57
Message: <3DDF71FE.409@ibras.dk>
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

From: Mark M  Wilson
Subject: Re: General question about relative efficiency of CSG operations
Date: 23 Nov 2002 11:12:28
Message: <3DDFA922.6443022C@att.net>
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

From: Mark M  Wilson
Subject: Re: General question about relative efficiency of CSG operations
Date: 23 Nov 2002 11:27:09
Message: <3DDFAC94.5392C1EC@att.net>
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

From: Mark M  Wilson
Subject: Re: General question about relative efficiency of CSG operations
Date: 23 Nov 2002 13:52:58
Message: <3DDFCEC1.E42ECD2B@att.net>
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

From: LibraryMan
Subject: Re: General question about relative efficiency of CSG operations
Date: 26 Nov 2002 16:16:07
Message: <3DE3E496.750A81EE@att.net>
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

<<< Previous 10 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.