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

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