I need to know what a "bounding slab" is. I also need to know what a "light
buffer" is. I want to know because they're making the parsing of a scene I'm
working on *really* slow. They happen right at the end after having read in
the POV file. I'm trying to make a forest with some Gilles Tran trees, and I
have 5 different trees which I place in different ways. I have some with a
recursion (is this the correct word?) of 3, and those go in the background,
some with 4 that go in the foreground and some with 6 that go right in the
front. When I put them all together the big slowdown happens. Individually
and they all parse pretty quickly. I don't get it.

PS: Does anyone have pictures of Dagobah, or some similar planet to put my
IRIDIA to explore on? The forest is my lame attempt at a Dagobah. It doesn't
look like the real thing at all, as best I can recall. TIA.

Post a reply to this message

TonyB wrote:

> I'm trying to make a forest with some Gilles Tran trees, and I
> have 5 different trees which I place in different ways. I have some with a
> recursion (is this the correct word?) of 3, and those go in the background,
> some with 4 that go in the foreground and some with 6 that go right in the
> front. When I put them all together the big slowdown happens. Individually
> and they all parse pretty quickly. I don't get it.

I never had much success using more than 3 trees in the same scene (sent the
hard drive into trashing frenzy), but perhaps you could try bounding each tree
using the box statement provided at the end of the *.inc files. This box is
there to assist tree placement, but I guess it could be used for manual
bounding.
I hope this helps.
G.

Post a reply to this message

Gilles Tran wrote:
> 
> TonyB wrote:
> 
> > I'm trying to make a forest with some Gilles Tran trees, and I
> > have 5 different trees which I place in different ways. I have some with a
> > recursion (is this the correct word?) of 3, and those go in the background,
> > some with 4 that go in the foreground and some with 6 that go right in the
> > front. When I put them all together the big slowdown happens. Individually
> > and they all parse pretty quickly. I don't get it.
> 
> I never had much success using more than 3 trees in the same scene (sent the
> hard drive into trashing frenzy), but perhaps you could try bounding each tree
> using the box statement provided at the end of the *.inc files. This box is
> there to assist tree placement, but I guess it could be used for manual
> bounding.
> I hope this helps.
> G.

I imagine with as many objects as the tree macro produces a LOT of bounding
boxes must be computed. It will sure help with the final render time but
the parse time suffers as a result. The amount of time to compute the light
buffers will also increase when there are many objects present in a scene.
Manual bounding might help with this but be sure to turn off automatic
bounding if you do or POV might just ignore your bounding.

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

On Thu, 24 Feb 2000 23:41:46 -0500, "TonyB"
<ben### [at] panamac-comnet> wrote:

>I need to know what a "bounding slab" is. I also need to know what a "light
>buffer" is. I want to know because they're making the parsing of a scene I'm
>working on *really* slow. They happen right at the end after having read in
>the POV file. I'm trying to make a forest with some Gilles Tran trees, and I
>have 5 different trees which I place in different ways. I have some with a
>recursion (is this the correct word?) of 3, and those go in the background,
>some with 4 that go in the foreground and some with 6 that go right in the
>front. When I put them all together the big slowdown happens. Individually
>and they all parse pretty quickly. I don't get it.

A bounding slab is the smallest box that an object fits in and that
has edges and walls parallel to the world coordinate axes. From what I
remember from FT-POV, a light buffer is similar to a vista buffer in
that it is a 2D projection of bounding boxes, but not on the screen
plane, rather on a very small sphere surrounding a point light source.
Then, when performing shadow-ray testing of a point against an object,
it is first checked if the shadow ray hits the projection (which is a
fast enough operation only involving comparison of a couple of angles)
and only if it does the actual ray-shape intersection test is
performed for the shadow ray. Put simply, there is a major benefit in
render time at the cost of parse time and memory consumption.


Peter Popov
pet### [at] usanet
ICQ: 15002700

Post a reply to this message

Ken wrote:

> I imagine with as many objects as the tree macro produces a LOT of bounding
> boxes must be computed. It will sure help with the final render time but
> the parse time suffers as a result. The amount of time to compute the light
> buffers will also increase when there are many objects present in a scene.
> Manual bounding might help with this but be sure to turn off automatic
> bounding if you do or POV might just ignore your bounding.

This is not necessary. In this case of manual bounding of unions, according to the
POV manual "if you do manually bound a union we presume you really want it bound.
For safety sake we do not presume to remove such bounds. " Never underestimate the
user-friendliness of the POV-team ;-)

G.

Post a reply to this message

In article <38B6B5FE.231EAF29@inapg.inra.fr>, Gilles Tran 
<tra### [at] inapginrafr> wrote:

> This is not necessary. In this case of manual bounding of unions, 
> according to the POV manual "if you do manually bound a union we 
> presume you really want it bound. For safety sake we do not presume 
> to remove such bounds. " Never underestimate the user-friendliness of 
> the POV-team ;-)

This is only true of unions, though.
The manual(the Holy Manual? :-) ) also says:
"Early versions of POV-Ray had no system of automatic bounding or 
spatial sub-division to speed up ray-object intersection tests. Users 
had to manually create bounding boxes to speed up the rendering. Since 
version 3.0, POV- Ray has had more sophisticated automatic bounding than 
any previous version. In many cases the manual bounding on older scenes 
is slower than the new automatic systems. Therefore POV-Ray removes 
manual bounding when it knows it will help. In rare instances you may 
want to keep manual bounding. Some older scenes incorrectly used 
bounding when they should have used clipping. If POV-Ray removes the 
bounds in these scenes the image will not look right. To turn off the 
automatic removal of manual bounds you should specify Remove_Bounds=off  
or use -UR . The default is Remove_Bounds=on ."

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Bounding slabs = automatically generated bounding boxes.
The light buffer and vista buffer are explained in the docs, in the automatic
bounding control section. I've found that turning them off can sometimes improve
render speed (as well as saving memory) with large numbers of objects. I'm even
under th impression that they are turned off automatically for triangle meshes.
May be wrong though.
Manually bounding the trees will save memory, but at the expense of trace time
(unless you come up with a very clever manual bounding scheme).

Margus

TonyB wrote:
> 
> I need to know what a "bounding slab" is. I also need to know what a "light
> buffer" is. I want to know because they're making the parsing of a scene I'm
> working on *really* slow. They happen right at the end after having read in
> the POV file. I'm trying to make a forest with some Gilles Tran trees, and I
> have 5 different trees which I place in different ways. I have some with a
> recursion (is this the correct word?) of 3, and those go in the background,
> some with 4 that go in the foreground and some with 6 that go right in the
> front. When I put them all together the big slowdown happens. Individually
> and they all parse pretty quickly. I don't get it.
> 
> PS: Does anyone have pictures of Dagobah, or some similar planet to put my
> IRIDIA to explore on? The forest is my lame attempt at a Dagobah. It doesn't
> look like the real thing at all, as best I can recall. TIA.

Post a reply to this message