POV-Ray : Newsgroups : povray.general : General question about relative efficiency of CSG operations Server Time
5 Aug 2024 10:26:43 EDT (-0400)
  General question about relative efficiency of CSG operations (Message 11 to 20 of 23)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 3 Messages >>>
From: LibraryMan
Subject: Re: General question about relative efficiency of CSG operations
Date: 22 Nov 2002 13:40:04
Message: <3DDE7A07.B6D66C46@att.net>
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

From: LibraryMan
Subject: Re: General question about relative efficiency of CSG operations
Date: 22 Nov 2002 14:24:34
Message: <3DDE8474.B77F6793@att.net>
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

From: LibraryMan
Subject: Re: General question about relative efficiency of CSG operations
Date: 22 Nov 2002 14:35:17
Message: <3DDE86F3.9FD3AFE6@att.net>
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

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

<<< Previous 10 Messages Goto Latest 10 Messages Next 3 Messages >>>

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