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


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

>
>

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

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





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

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

> >
> >

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

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

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