> I'm drawing a building, rendering it with V 3.1. (Willing to switch up,
> if it'll help, tho. It just happens to be what I have.)
>
> If I trace it at +Q3 with no AA, it renders some 3000 pixels per second.
> If I trace it at +Q4 with no AA, it renders at some 3 pixels per second.
> Now, the building consists basically of
>
> intersection {
>    union {
>      ... lots of walls ...
>     }
>     union {
>       ... all the doorways and windows ...
>     }
>   }

The main problem with CSG is bounding. If you subtract some bunch of objects
from some other bunch of objects, how do you expect POV-Ray to know what
gets subtracted and where?

So, if you want to cut a window from a wall, do that by itself:
difference{ object{Wall} object{Window} }

(Don't know why you're using Intersection in your post).

With one large intersection, POV-Ray will test EACH and EVERY object of that
intersection group for shadow rays, insidedness tests (the CSG effect,
so-to-speak) and so forth (okay, I'm no expert on the actual code, so it
might not be each and every object, but it sure is a hell lot more to
compute for POV-Ray).

One thing DigitalTwilight once made was a castle. He put the entire castle
into a merge{} statement, don't ask me why. The result was a MUCH slower
rendering. Using "-UD" on the commandline shows the boundary boxes. He had
just one. What POV-Ray does internally I do not know, but one (1!) box
versus the expected 500 (especially since his castle was made with many,
many boxes for the walls etc) is obviously a great disadvantage. Just
experiment with that yourself, and you'll see.

I hope this little excursion helps you.

Regards,
Tim

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de

Post a reply to this message

Wasn't it Darren who wrote:
>I'm drawing a building, rendering it with V 3.1. (Willing to switch up, 
>if it'll help, tho. It just happens to be what I have.)
>
>If I trace it at +Q3 with no AA, it renders some 3000 pixels per second. 
>If I trace it at +Q4 with no AA, it renders at some 3 pixels per second.
>
>Yep. a 1000:1 hit there, apparently to calculate the shadows.
>
>Now, the building consists basically of
>
>intersection {
>   union {
>     ... lots of walls ...
>    }
>    union {
>      ... all the doorways and windows ...
>    }
>  }
>followed by lights, furniture, etc. The lights are all point sources 
>with various falloffs.

It might be worth a look at my POV holes tutorial
<http://www.econym.demon.co.uk/holetut.htm>

That tutorial talks about differences rather than intersections, but
some of the general principles may well apply. In particular observe how
the tutorial examines the POV statistics to see where all the time goes.
If you compare the +Q3 with the +Q4 stats (render a tiny image or the
same small region of the image if it takes too long) it's possible that
you might spot some interesting differences that might give you a clue.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Darren <dne### [at] sanrrcom> wrote:
> Now, the building consists basically of

> intersection {
>    union {
>      ... lots of walls ...
>     }
>     union {
>       ... all the doorways and windows ...
>     }
>   }

  Using enormous amounts of objects in an intersection will definitely
slow down a lot. You have probably found one of the most patological
cases. :)

  I recommend remodelleing your building without using intersection
(nor difference, of course).

  One way (I think) is to make more intersections (or differences) with
less objects. Something like this:

union
{ intersection { ... Wall 1 ... }
  intersection { ... Wall 2 ... }
  intersection { ... Wall 3 ... }
  ...
}

  (I haven't actually tested this will be faster, but if my logic is
correct, it should be.)

  Another way is to avoid intersection/difference completely.
  For example, if you have a wall with a window made with the difference
of two boxes, replace it with the union of four boxes instead. There will
be more primitives, but since there's no CSG it will probably be faster
when the number of walls grows.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

On Thu, 12 Feb 2004 16:15:30 -0800, Darren <dne### [at] sanrrcom> wrote:

>I'm drawing a building, rendering it with V 3.1. (Willing to switch up, 
>if it'll help, tho. It just happens to be what I have.)
>
>If I trace it at +Q3 with no AA, it renders some 3000 pixels per second. 
>If I trace it at +Q4 with no AA, it renders at some 3 pixels per second.
>
>Yep. a 1000:1 hit there, apparently to calculate the shadows.
>
>Now, the building consists basically of
>
>intersection {
>   union {
>     ... lots of walls ...
>    }
>    union {
>      ... all the doorways and windows ...
>    }
>  }
>followed by lights, furniture, etc. The lights are all point sources 
>with various falloffs.
>[...]

I've posted a patch for an improved intersection routine in p.b.p some
days ago  (<news:4003c00f.84804802@news.povray.org>) which should give
you a significant speed up.
It should be easy to integrate it into 3.1 (the posted patch is for
3.5) but I don't have the sources of 3.1 anymore. I could give you a
Windows 3.5 binary (which probably requires that you 1st install the
official version).
I could do a test render on my machine if you are willing to share the
current (or a comparable) version of your scene to get some timing
values for my version.


-- 
Andreas

Post a reply to this message

Wasn't it Darren who wrote:

>First, a difference is actually an intersection with everything but the 
>first item having its "inside" and "outside" swapped, right? So
>   difference { box {...}  sphere {...} }
>is the same as
>   intersection { box { ... } sphere {... inverted} }
>right? If that's the case, why can't Pov-Ray figure out what the 
>bounding box is? Surely it can't be bigger than the bounding box of the 
>first item?

That's right, it's just that POV can't automatically determine any
tighter bounds than that. In some circumstances it's possible to
manually construct bounds that are very much better than that. This
tends to happen if the difference/intersection removes the majority of
the first object and in situations where there are a large number of
small holes.

>Secondly, if I have a bunch of walls, a bunch of lights, and a bunch of 
>holes in the walls, even with my back to the walls, doesn't PovRay have 
>to consider all the holes and all the lights to figure out what shadows 
>I see? I mean, picture stonehenge with many campfires inside, in turn 
>inside an airplane hanger. If I'm standing outside the ring facing away, 
>  how does PovRay know what to show me as light and dark on the wall 
>without having to consider a large number of holes anyway?

It still has to consider all the holes, but with good manual bounding it
would be possible for POV to know which holes to consider for each
individual ray that it traces. With weak bounding, POV has to test every
hole *for*every*ray* from every campfire. If there are lots of holes and
lots of rays that can sometimes be quite slow. Common sense may tell us
that a ray travelling North doesn't need to be tested to see if it
passes through a hole on the South side of the structure, but without
good bounding POV doesn't have a clue, so it performs an intersection
test. 

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

On Fri, 13 Feb 2004 22:59:59 -0800, Darren <dne### [at] sanrrcom> wrote:

>Mike Williams wrote:
>> That's right, it's just that POV can't automatically determine any
>> tighter bounds than that. In some circumstances it's possible to
>> manually construct bounds that are very much better than that.
>
>Hmmm. Well, right now, I'm manually putting in bounds that are the wall 
>the windows are in.

IMHO this will only slow down the renderer as your manual bounds are
identical to the walls.

>
>On the other hand, I used to be unioning together all the walls, then 
>all the windows, so I guess the bounding box would be the whole building 
>in that case. I can see where that would be problematic.

Here is the problem.
You should do it the other way round. Create each wall as a difference
object where it's windows and doors are 'subtracted'.
Then put them into a union to create the buildings.
This will speed up your rendering and you will not benefit much from
my patch.

>I'll try some cameras with the bounds in, and try commenting out the 
>manual bounds, and see if the speed changes noticably. Just doing the 
>outside walls seems to have sped me up to some 300 pps with both 
>textures and AA turned on, so that's looking very promising.
>
>> With weak bounding, POV has to test every
>> hole *for*every*ray* from every campfire.
>
>Got it. So you could think of it like each campfire being a camera as 
>well, and the problem is essentially the same.
>
>Thanks for all the advice, everyone! This is a very friendly and helpful 
>group!


-- 
Andreas

Post a reply to this message

"Darren" <dne### [at] sanrrcom> wrote in message
news:40307c69$1@news.povray.org...
>
> And ... what does "Warning - No pigment type given" mean? All my
> pigments are either typed or of the form
>    pigment { color rgbf<...> } or pigment { color Red }
> And the error message just points to where I invoke the union, so I get
> 100 of these warnings on the same line. :-) What syntax can I look for
> to eliminate that?

Mike would probably get around to answering this for you, I just happen to
be reading this and looked at your files and see in the World.pov that there
are a series of boxes without textures or pigments interleaved within the
object named ExteriorWalls0. Not sure what part they play in this scene
file. A solution to the "No pigment given" warning is to set a #default
{texture {pigment {color rgb 0}}} statement at the beginning of the file. Of
course, you'll want to use an actual texture consistant with the object. If
this were using 'difference' or 'intersection' instead of 'union' you would
also want to use cutaway_textures in the CSG statement, I believe so anyhow.
I didn't render the entire scene to find out what affect this all has
visually.

-- 
Bob H.
http://www.3digitaleyes.com

Post a reply to this message

"Darren" <dne### [at] sanrrcom> wrote in message
news:40311547$1@news.povray.org...
>
> > also want to use cutaway_textures in the CSG statement, I believe so
anyhow.
>
> Ah! That must be new in 3.5? Cool. That's exactly what I'm looking for.
> I'll need to go fix all my rgbt<1,1,1,1> to cutaway_textures. Thanks!

Yikes! Don't go putting something into each and every box primitive to fix
things since a #default {texture {pigment {color rgbt 1}}} would have done
the same thing. In fact, simply another texture statement (the one used for
the wall) added to the end of the entire CSG statement will also work and
still retain any other textures already applied. Adding an identical texture
to 100 separate objects individually is too cumbersome.

The cutaway_textures keyword also goes in the end of the CSG statement, not
into individual objects, so you only need it once for a CSG difference. Not
going to help for unions though. I suppose you might have already learned
all this, I just wanted to clarify things.

-- 
Bob H.
http://www.3digitaleyes.com

Post a reply to this message

On Sun, 15 Feb 2004 21:43:35 -0800, Darren <dne### [at] sanrrcom> wrote:

>> Yeah. I see now. It just took me a while to understand what I was doing 
>> wrong and why it would be slow. 
>
>Well, it seems to be much improved, altho not as fast as I'd like. (Is 
>it ever?)

No. As I can see from your scene file you want to use area lights
later :-)

>I've also upgraded to 3.5.
>
>With all the lights in place (Maybe 150 or 200 torches, each actually 
>being two light sources) it runs some hundred or two PPS with AA turned 
>on at +Q5. I'll be happy if I can keep it in the tripple digits, I think.

I've just traced Keep_33_37_0_sw.pov (640 x 480, AA=0.3).
It took 3 hours and 5 minutes.
Commenting out the lights it needed 6 seconds.
It's the number of light sources that slows down your scene.
For each visible surface point a ray is traced to each of the light
sources to see whether it contributes or is blocked (which is probably
almost always the case).
If your scene generator can put the 

>I tried taking the whole castle and setting it clipped_by and bounded_by 
>just one corner, and it didn't render anything outside the box, but it 
>didn't render noticably faster either, even tho I clipped out most of 
>the lights.

???
Clipping/bounding an object (the 'torch' union?) doesn't affect (hide)
the light sources that are defined inside of them.
What do you mean with 'clipped out most of the lights'?

>I don't notice any especially inefficient ray tests, either.

They are as efficient as possible :-)

>Are there other clues? Maybe some way of clipping out areas I know don't 
>affect the final scene without actually changing the building code on 
>the fly?  (I could use the macros to nuke out large chunks of the 
>building as appropriate, but I'd rather do it without having to 
>basically #ifdef out the rooms I'm not currently rendering with this 
>particular camera.)
>
>I know it's hard to answer such a thing without seeing source. (And I'm 
>happy to show people source if they care, but it's ugly, since it's 
>automatically generated.) But ... is there anything else I should be 
>looking at?  Are the lights going to spectacularly slow down rendering?

Yes.
 
>Maybe if I just comment out particular blocks of lights when I'm not 
>rendering near the camera?

If you can group the lights somehow (maybe room1, room2, ...)
this will probably help to selectively 'switch' them on and off which
will definitely speed up the rendering.
If your scene generator is able to do this you should have a look at
the new 'light_group' object.
It enables you to restrict the lighting of a light source to the
objects that are declared together with the light source.


-- 
Andreas

Post a reply to this message

Wasn't it Darren who wrote:
>
>Thanks for your private email, but you didn't give me an email address 
>to reply to. :-)

To reply to one of my emails, just click [Reply].

> In any case, it's at 
>http://home.san.rr.com/dnew/PovSource.zip

It's easy to see that it's not the classic difference bounding problem.
Temporarily globally replacing "difference" with "union" produces a
scene that only renders twice as fast. That's about what you'd expect if
the differences are efficiently bounded, the extra time is taken up by
the fact that some rays pass through windows and thus need additional
intersection tests to see if they hit any further objects.

I reckon that you're not going to get it to go much faster while having
248 shadow-casting light sources. Perhaps you could change many of the
lights to be shadowless.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message