I made a scene of a stone wall. The stones were created as individual
objects (a couple hundred of 'em), and the scene rendered properly in about
30 minutes at 1024x768 resolution. I decided to make a single "BrickWall"
object (using a macro) that was a union of all the individual stones, and
suddenly it took almost NINE HOURS to render the same scene, although it
looked the same! Did I do something wrong? Is there a solution to this
problem? I would like to keep the union so that I can easily manipulate
multiple stone walls in my scene.

Regards,
Dave

Post a reply to this message

BTW, I should have mentioned that peak memory used is only about 12MB with
the CSG Union version, and my computer has 128MB RAM. There's no disk
thrashing going on, but maybe this is a CPU cache issue?

Post a reply to this message

On Sat, 20 May 2000 00:46:43 -0700, "Dave Blandston"
<gra### [at] earthlinknet> wrote:

>BTW, I should have mentioned that peak memory used is only about 12MB with
>the CSG Union version, and my computer has 128MB RAM. There's no disk
>thrashing going on, but maybe this is a CPU cache issue?

No, not at all. It's related to bounding. Are you using manual
bounding? Is automatic counding on? Most importantly, is union
splitting on? How about removing user bounds (if any)? Are vista and
light buffers on?

What is most probably happening is that for some reason (a bad
combination of settings) POV is checking each ray against all objects
in the scene. As a quick test, try these command line options:

+mb0 +ul +uv +ur +su

If this does not work, read the docs :) especially the chapter about
automatic bounding control and removing user bounds.

HTH


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

I have this problem rendering thousands of blades of grass, I've never found
a solution that really works, though Peter's suggestion sometimes has a
small effect.

Mick
"Peter Popov" <pet### [at] usanet> wrote in message
news:i1lciskkd7l89lm1gfa3ocom0298vrtu35@4ax.com...
> On Sat, 20 May 2000 00:46:43 -0700, "Dave Blandston"
> <gra### [at] earthlinknet> wrote:
>
> >BTW, I should have mentioned that peak memory used is only about 12MB
with
> >the CSG Union version, and my computer has 128MB RAM. There's no disk
> >thrashing going on, but maybe this is a CPU cache issue?
>
> No, not at all. It's related to bounding. Are you using manual
> bounding? Is automatic counding on? Most importantly, is union
> splitting on? How about removing user bounds (if any)? Are vista and
> light buffers on?
>
> What is most probably happening is that for some reason (a bad
> combination of settings) POV is checking each ray against all objects
> in the scene. As a quick test, try these command line options:
>
> +mb0 +ul +uv +ur +su
>
> If this does not work, read the docs :) especially the chapter about
> automatic bounding control and removing user bounds.
>
> HTH
>
>
> Peter Popov ICQ : 15002700
> Personal e-mail : pet### [at] usanet
> TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Thank you, sirs. At least it's nice to know what's going on now - I was
baffled - haven't even thought about bounding since version 2.

Regards,
Dave

"Mick Hazelgrove" <mha### [at] redhotantcom> wrote in message
news:3926a822$1@news.povray.org...
> I have this problem rendering thousands of blades of grass, I've never
found
> a solution that really works, though Peter's suggestion sometimes has a
> small effect.
>
> Mick
> "Peter Popov" <pet### [at] usanet> wrote in message
> news:i1lciskkd7l89lm1gfa3ocom0298vrtu35@4ax.com...
> > On Sat, 20 May 2000 00:46:43 -0700, "Dave Blandston"
> > <gra### [at] earthlinknet> wrote:
> >
> > >BTW, I should have mentioned that peak memory used is only about 12MB
> with
> > >the CSG Union version, and my computer has 128MB RAM. There's no disk
> > >thrashing going on, but maybe this is a CPU cache issue?
> >
> > No, not at all. It's related to bounding. Are you using manual
> > bounding? Is automatic counding on? Most importantly, is union
> > splitting on? How about removing user bounds (if any)? Are vista and
> > light buffers on?
> >
> > What is most probably happening is that for some reason (a bad
> > combination of settings) POV is checking each ray against all objects
> > in the scene. As a quick test, try these command line options:
> >
> > +mb0 +ul +uv +ur +su
> >
> > If this does not work, read the docs :) especially the chapter about
> > automatic bounding control and removing user bounds.
> >
> > HTH
> >
> >
> > Peter Popov ICQ : 15002700
> > Personal e-mail : pet### [at] usanet
> > TAG      e-mail : pet### [at] tagpovrayorg
>
>

Post a reply to this message

I have had this problem once.

Use 'merge' instead of 'union' and manually bound it with a bounded_by { sphere
or box } as closely as possible.

POV will consider your wall as a single block and not as thousand of bricks.

It worked when I had thousands of spheres to render. Hope it will for you too.

Fabien Hénon


Dave Blandston a écrit :

> I made a scene of a stone wall. The stones were created as individual
> objects (a couple hundred of 'em), and the scene rendered properly in about
> 30 minutes at 1024x768 resolution. I decided to make a single "BrickWall"
> object (using a macro) that was a union of all the individual stones, and
> suddenly it took almost NINE HOURS to render the same scene, although it
> looked the same! Did I do something wrong? Is there a solution to this
> problem? I would like to keep the union so that I can easily manipulate
> multiple stone walls in my scene.
>
> Regards,
> Dave

Post a reply to this message

I'm not sure I follow you. Do you mean that you bounded the entire merge
object? I tried that (with the "-ur" switch), and didn't see a noticeable
change in render speed.

BTW, I posted a picture of the brick wall on p.b.i.

Regards,
Dave

"Fabien Hénon" <ffj### [at] club-internetfr> wrote in message
news:3926B770.3CD55E5E@club-internet.fr...
> I have had this problem once.
>
> Use 'merge' instead of 'union' and manually bound it with a bounded_by
 sphere
> or box } as closely as possible.
>
> POV will consider your wall as a single block and not as thousand of
bricks.
>
> It worked when I had thousands of spheres to render. Hope it will for you
too.
>
> Fabien Hénon
>
>
> Dave Blandston a écrit :
>
> > I made a scene of a stone wall. The stones were created as individual
> > objects (a couple hundred of 'em), and the scene rendered properly in
about
> > 30 minutes at 1024x768 resolution. I decided to make a single
"BrickWall"
> > object (using a macro) that was a union of all the individual stones,
and
> > suddenly it took almost NINE HOURS to render the same scene, although it
> > looked the same! Did I do something wrong? Is there a solution to this
> > problem? I would like to keep the union so that I can easily manipulate
> > multiple stone walls in my scene.
> >
> > Regards,
> > Dave
>

Post a reply to this message

On Sat, 20 May 2000 18:04:00 +0200, Fabien Hénon
<ffj### [at] club-internetfr> wrote:

>Use 'merge' instead of 'union' and manually bound it with a bounded_by { sphere
>or box } as closely as possible.

Merge is internally represented as a complex CSG. It takes more memory
and generally takes longer to render than the equivalent union. This
is not true in some special cases but this shouldn't be one of them.

>POV will consider your wall as a single block and not as thousand of bricks.

Wrong (I think). It just represents it as a complex CSG to remove the
inner surfaces.

>It worked when I had thousands of spheres to render. Hope it will for you too.

If the spheres were transparent and stacked, maybe. I doubt it will
help in the stones macro case.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

I tried on my side with a test scene with 1000 spheres..., but I have not seen
any changes either.
Sorry about that.
I guess the solution I suggested only works with a previous version of POV 3.0
or 2.2 ( I forgot, it was a long time ago).

Fabien Hénon

Dave Blandston a écrit :

> I'm not sure I follow you. Do you mean that you bounded the entire merge
> object? I tried that (with the "-ur" switch), and didn't see a noticeable
> change in render speed.
>
> BTW, I posted a picture of the brick wall on p.b.i.
>
> Regards,
> Dave
>
> "Fabien Hénon" <ffj### [at] club-internetfr> wrote in message
> news:3926B770.3CD55E5E@club-internet.fr...
> > I have had this problem once.
> >
> > Use 'merge' instead of 'union' and manually bound it with a bounded_by
>  sphere
> > or box } as closely as possible.
> >
> > POV will consider your wall as a single block and not as thousand of
> bricks.
> >
> > It worked when I had thousands of spheres to render. Hope it will for you
> too.
> >
> > Fabien Hénon
> >
> >
> > Dave Blandston a écrit :
> >
> > > I made a scene of a stone wall. The stones were created as individual
> > > objects (a couple hundred of 'em), and the scene rendered properly in
> about
> > > 30 minutes at 1024x768 resolution. I decided to make a single
> "BrickWall"
> > > object (using a macro) that was a union of all the individual stones,
> and
> > > suddenly it took almost NINE HOURS to render the same scene, although it
> > > looked the same! Did I do something wrong? Is there a solution to this
> > > problem? I would like to keep the union so that I can easily manipulate
> > > multiple stone walls in my scene.
> > >
> > > Regards,
> > > Dave
> >

Post a reply to this message

On Sat, 20 May 2000 00:12:07 -0700, "Dave Blandston"
<gra### [at] earthlinknet> wrote:

>I made a scene of a stone wall. The stones were created as individual
>objects (a couple hundred of 'em), and the scene rendered properly in about
>30 minutes at 1024x768 resolution. I decided to make a single "BrickWall"
>object (using a macro) that was a union of all the individual stones, and
>suddenly it took almost NINE HOURS to render the same scene, although it
>looked the same! Did I do something wrong? Is there a solution to this
>problem? I would like to keep the union so that I can easily manipulate
>multiple stone walls in my scene.

Dave,

I didn't have much time to test your code but here's the little I have
found so far:

1. Antialiasing slows it down immensely
2. Manuallly bounding each NewBrick object in a unit box gives a
10-20% speedup

POV reports 2 frame level objects and these are the two walls. I
haven't ventured deep in your code (though, I must admit, it is among
the top five I've seen, style-wise) but I found that a wall is a CSG
intersection of a box and the union of the mortar and bricks. This
makes it one object in terms of bounding so even with the vista buffer
on POV has to test 30% of the images on the screen against all stones,
which are CGSs of superellipsoids and height fields. I am pretty sure
that if, instead of intersecting above box with the union of the
bricks, you make a union of the intersections of this box with every
single brick, it will speed up the render considerably, because every
brick will then be bounded individually and rays will only be tested
against it when necessary.

There might be other optimisations to make, like using clipped_by
instead of intersection etc. but if what I propose works as I hope it
would, you'll have more time to experiment with extra speedup tweaks.

Hope it works...


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Peter,

You are amazing. That's the solution! The walls now render in a "normal"
amount of time! I would never have figured that out by myself. Thanks so
much for helping me out. I just want to give you a big, wet kiss. If you
will send me your T-shirt size and address I want to make a cool Metallica
Creeping Death/Crypt T-shirt for you.

Thank you sir,
Dave
gra### [at] earthlinknet

"Peter Popov" <pet### [at] usanet> wrote in message
news:5dogis0qqnuaig9coemjn6vu6kdm80ribn@4ax.com...
> I didn't have much time to test your code but here's the little I have
> found so far:
>
> 1. Antialiasing slows it down immensely
> 2. Manuallly bounding each NewBrick object in a unit box gives a
> 10-20% speedup
>
> POV reports 2 frame level objects and these are the two walls. I
> haven't ventured deep in your code (though, I must admit, it is among
> the top five I've seen, style-wise) but I found that a wall is a CSG
> intersection of a box and the union of the mortar and bricks. This
> makes it one object in terms of bounding so even with the vista buffer
> on POV has to test 30% of the images on the screen against all stones,
> which are CGSs of superellipsoids and height fields. I am pretty sure
> that if, instead of intersecting above box with the union of the
> bricks, you make a union of the intersections of this box with every
> single brick, it will speed up the render considerably, because every
> brick will then be bounded individually and rays will only be tested
> against it when necessary.
>
> There might be other optimisations to make, like using clipped_by
> instead of intersection etc. but if what I propose works as I hope it
> would, you'll have more time to experiment with extra speedup tweaks.
>
> Hope it works...
>
>
> Peter Popov ICQ : 15002700
> Personal e-mail : pet### [at] usanet
> TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Fabien Hénon <ffj### [at] club-internetfr> wrote:
: POV will consider your wall as a single block and not as thousand of bricks.

  The fact that it looks like a single block doesn't mean it is internally
represented as an internal block.
  Actually it's represented as a series of intersections of inverted objects
or something like that.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Peter Popov wrote:
> No, not at all. It's related to bounding. Are you using manual
> bounding? Is automatic counding on? Most importantly, is union
> splitting on? How about removing user bounds (if any)? Are vista and
> light buffers on?

I have made the experience once in the exact same setup.
I realised that you have to "help" POV-Ray a little bit
with the bounding (I made the bricks in a nested loop
and then decided to manually bound every "line" of the
wall and then the whole wall). After that it was as
fast as w/o CSG.

Markus

Post a reply to this message

On Sun, 21 May 2000 21:52:05 -0700, "Dave Blandston"
<gra### [at] earthlinknet> wrote:

>Peter,
>
>You are amazing. That's the solution! The walls now render in a "normal"
>amount of time! I would never have figured that out by myself. Thanks so
>much for helping me out. I just want to give you a big, wet kiss. If you
>will send me your T-shirt size and address I want to make a cool Metallica
>Creeping Death/Crypt T-shirt for you.
>
>Thank you sir,
>Dave

<speechless>

*blush*

</speechless>


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Mike Williams' enhancement sped things up even more. Thanks to everyone who
helped out...

The sample scene in p.b.i. (DBStones.pov) sped up a LOT. It was taking my
computer almost 9 hours to render @ 1024x768 aa.3 before y'all's
suggestions, and back to under 30 minutes after the optomizations. The
actual scene that I made the macro for, however, saw a less significant
improvement, but it still renders in about 5-6 hours. Radiosity and/or media
in the scene is out of the question, though, as long as the stones are used.
Render time becomes astro-freakin'-nomical. No moonbeams shining in through
the crypt window. :(

Regards,
Dave

Post a reply to this message

On Sun, 21 May 2000 11:00:52 +0300, Peter Popov wrote:
>On Sat, 20 May 2000 18:04:00 +0200, Fabien Hénon
><ffj### [at] club-internetfr> wrote:
>
>>Use 'merge' instead of 'union' and manually bound it with a bounded_by { sphere
>>or box } as closely as possible.
>
>Merge is internally represented as a complex CSG. It takes more memory
>and generally takes longer to render than the equivalent union. This
>is not true in some special cases but this shouldn't be one of them.

Actually, it is internally represented as a merge.  Difference is the
operation you're thinking of.  Merge takes no more memory than the 
equivalent union, and whether it takes more time depends on whether
it takes longer to do intersection checks or to compute texture 
(including reflected and transmitted rays) which depends on what 
type of objects you're working with.

In this case, a ray will never hit internal walls anyway, so there is
probably no difference in speed.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
These are my opinions.  I do NOT speak for the POV-Team.

Post a reply to this message

On 22 May 2000 03:55:44 -0400, Warp wrote:
>  Actually it's represented as a series of intersections of inverted objects
>or something like that.

Nope.  It could be, but it's not, and changing it didn't help the speed
any so it remains the way it was, as a separate CSG type.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
These are my opinions.  I do NOT speak for the POV-Team.

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: Nope.  It could be, but it's not

  How is it represented then?
  I remember this was a question in the 'hard-core povrayer test'. Someone
said it's represented as an intersection of inverted objects or something
similar, if I remember correctly.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On 24 May 2000 03:56:35 -0400, Warp wrote:
>Ron Parker <ron### [at] povrayorg> wrote:
>: Nope.  It could be, but it's not
>
>  How is it represented then?

It's represented as a merge.  There are special cases in the code for
merges.  IIRC, it could be represented as the inverse of the intersections
of the inverses of the constituent objects, but it isn't.

>  I remember this was a question in the 'hard-core povrayer test'. Someone
>said it's represented as an intersection of inverted objects or something
>similar, if I remember correctly.

Difference is represented as an intersection.  Perhaps that's what you're
thinking of.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
These are my opinions.  I do NOT speak for the POV-Team.

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: It's represented as a merge.  There are special cases in the code for
: merges.  IIRC, it could be represented as the inverse of the intersections
: of the inverses of the constituent objects, but it isn't.

  What is the algorithm for the ray-intersection test for merges (briefly
and clearly exaplained, if possible :) )? I'm interested in knowing it.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On 24 May 2000 09:17:50 -0400, Warp wrote:
>Ron Parker <ron### [at] povrayorg> wrote:
>: It's represented as a merge.  There are special cases in the code for
>: merges.  IIRC, it could be represented as the inverse of the intersections
>: of the inverses of the constituent objects, but it isn't.
>
>  What is the algorithm for the ray-intersection test for merges (briefly
>and clearly exaplained, if possible :) )? I'm interested in knowing it.

1. Find all intersections.
2. Pop an intersection off the stack.  If none remains, no intersection
   with this object occurred.
3. Test to see if that intersection is inside any subobject other than the
   one it is on the surface of.  If so, throw it away and go to 2.
4. That's it.  Do whatever you do with the intersection you now have.  Don't
   forget to flush the stack, put the seat down, and turn off the light.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
These are my opinions.  I do NOT speak for the POV-Team.

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: 1. Find all intersections.
: 2. Pop an intersection off the stack.  If none remains, no intersection
:    with this object occurred.
: 3. Test to see if that intersection is inside any subobject other than the
:    one it is on the surface of.  If so, throw it away and go to 2.

  Yes, pretty simple.
  How do you know that the point is inside an object? You ask that
object "hey! is this point inside you?"?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On 24 May 2000 11:05:52 -0400, Warp wrote:
>  How do you know that the point is inside an object? You ask that
>object "hey! is this point inside you?"?

Yes, exactly.  That's one of the reasons meshes (in the official POV)
can't be used in CSG: they don't have a proper implementation of that
method.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
These are my opinions.  I do NOT speak for the POV-Team.

Post a reply to this message

On 23 May 2000 22:01:44 -0400, ron### [at] povrayorg (Ron Parker)
wrote:

>>Merge is internally represented as a complex CSG. It takes more memory
>>and generally takes longer to render than the equivalent union. This
>>is not true in some special cases but this shouldn't be one of them.
>
>Actually, it is internally represented as a merge.  Difference is the
>operation you're thinking of.  

I know a difference is an intersection with the inverse. What I meant
was that merge { object { A } object { B } } is equivalent to 

union 
{ intersection { object { A } object { B inverse } }
  intersection { object { B } object { A inverse } }
}

>In this case, a ray will never hit internal walls anyway, so there is
>probably no difference in speed.

Merging may have actually helped (the problem has been solved by
manual bounding etc.) if it helped POV bound the individual stones. I
can't say more without testing it.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

On Thu, 25 May 2000 00:51:27 +0300, Peter Popov wrote:
>On 23 May 2000 22:01:44 -0400, ron### [at] povrayorg (Ron Parker)
>wrote:
>
>>>Merge is internally represented as a complex CSG. It takes more memory
>>>and generally takes longer to render than the equivalent union. This
>>>is not true in some special cases but this shouldn't be one of them.
>>
>>Actually, it is internally represented as a merge.  Difference is the
>>operation you're thinking of.  
>
>I know a difference is an intersection with the inverse. What I meant
>was that merge { object { A } object { B } } is equivalent to 
>
>union 
>{ intersection { object { A } object { B inverse } }
>  intersection { object { B } object { A inverse } }
>}

This is the symmetric difference, equivalent to

difference {
  union {object {A} object {B}}
  intersection {object {A} object {B}}
}

(except for the coincident surface problems the latter causes) and 
logically similar to exclusive-or.

I think merge is actually equivalent to

intersection {
  object { A inverse }
  object { B inverse }
  inverse
}

but it's not represented that way internally.  The code actually has
special cases for merge, unlike for difference.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
These are my opinions.  I do NOT speak for the POV-Team.

Post a reply to this message

On 24 May 2000 18:26:36 -0400, ron### [at] povrayorg (Ron Parker)
wrote:

>I think merge is actually equivalent to
>
>intersection {
>  object { A inverse }
>  object { B inverse }
>  inverse
>}

It certainly looks like it, yes. Thanks for the info.

>but it's not represented that way internally.  The code actually has
>special cases for merge, unlike for difference.

Yes, I saw your reply to Warp after I posted :)


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message