I posted this a long time ago, but just realized the bug still exists, and
it's not in the known bugs list.

In the following scene, even though the camera shouldn't be able to see any
of the three sphere_sweeps or their bounding boxes, if you render with +UD,
to show the vista buffer, you can see that the bounding boxes of the sphere
sweeps are extended to include the point <0,0,0>. It doesn't happen if you
remove any of the three sphere_sweeps.

I noticed this when trying to render a scene with hundreds of sphere_sweeps,
and it took forever to render. Turning on +UD showed tons of bounding boxes,
all extended to include the origin.

Confirmation?

//+UD
camera {location <-10,10,-10> look_at 0}
light_source {<-100,100,-100> rgb 1}

sphere_sweep {
 linear_spline,
 2,
 40, .1
 50, .1
}
sphere_sweep {
 linear_spline,
 2,
 60, .1
 70, .1
}
sphere_sweep {
 linear_spline,
 2,
 90, .1
 100, .1
}

Win '98, 256 MB RAM, 900mhz P3 (i think).

- Slime
[ http://www.slimeland.com/ ]
[ http://www.slimeland.com/images/ ]

Post a reply to this message

Oh, one more thing: it appears that if you put the sphere_sweeps inside a
merge{}, the problem goes away (thankfully). A union{} doesn't work.

- Slime
[ http://www.slimeland.com/ ]
[ http://www.slimeland.com/images/ ]

Post a reply to this message

In article <3c3f6ab2$1@news.povray.org> , "Slime" <noo### [at] hotmailcom> 
wrote:

> I posted this a long time ago, but just realized the bug still exists, and
> it's not in the known bugs list.
>
> In the following scene, even though the camera shouldn't be able to see any
> of the three sphere_sweeps or their bounding boxes, if you render with +UD,
> to show the vista buffer, you can see that the bounding boxes of the sphere
> sweeps are extended to include the point <0,0,0>. It doesn't happen if you
> remove any of the three sphere_sweeps.
>
> I noticed this when trying to render a scene with hundreds of sphere_sweeps,
> and it took forever to render. Turning on +UD showed tons of bounding boxes,
> all extended to include the origin.

While the bounding boxes can probably be changed for efficiency, you should
be aware that there is and cannot be any guarantee that an automatic
bounding box will be a tight bound around an object, no matter what the
object type is.  All the bounding box has to be is somewhere outside the
object, but you simply cannot expect it to be a tight bound.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

> All the bounding box has to be is somewhere outside the
> object, but you simply cannot expect it to be a tight bound.

True, but the closest sphere_sweep from the origin goes from <40,40,40> to
<50,50,50>, with a radius of 1/10. There's no way its bounding box should
come anywhere close to the origin. And that doesn't explain why its bounding
box *stops* including the origin when you remove any one of the three
sphere_sweeps, or enclose them all inside a merge{}.

I discovered this bug when placing hundreds of very tiny sphere_sweeps very
far from the origin, and the bounding boxes of all of them appeared to be
the smallest box that could contain both the entire sphere_sweep *and* the
origin, creating very huge bounding boxes, and a very slow rendering time.

- Slime
[ http://www.slimeland.com/ ]
[ http://www.slimeland.com/images/ ]

Post a reply to this message

Wasn't it Slime who wrote:
>I posted this a long time ago, but just realized the bug still exists, and
>it's not in the known bugs list.
>
>In the following scene, even though the camera shouldn't be able to see any
>of the three sphere_sweeps or their bounding boxes, if you render with +UD,
>to show the vista buffer, you can see that the bounding boxes of the sphere
>sweeps are extended to include the point <0,0,0>. It doesn't happen if you
>remove any of the three sphere_sweeps.
>
>I noticed this when trying to render a scene with hundreds of sphere_sweeps,
>and it took forever to render. Turning on +UD showed tons of bounding boxes,
>all extended to include the origin.
>
>Confirmation?

Confirmed.

It also affects min_extent() or max_extent(), even if there's only one
sphere_sweep in the scene. The reason that you only see the problem when
there are three objects in the scene is that POV doesn't bother using
vista buffers when there are less than three objects.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

In article <3c3fa559$1@news.povray.org> , "Slime" <noo### [at] hotmailcom> 
wrote:

> And that doesn't explain why its bounding
> box *stops* including the origin when you remove any one of the three
> sphere_sweeps

Because of your bounding threshold?  If you reduce the number below the
threshold the bounding will go away.

As for the bounding itself, I think I have found a way how to place it
closer around the spheresweep.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

> Because of your bounding threshold?  If you reduce the number below the
> threshold the bounding will go away.

Sorry, I'm not sure what a bounding threshold is...

but maybe this will convince you: if you translate the shapes, their
bounding boxes should move with them, right? Try translating them all by
<1000,1000,1000> or something, and the bounding boxes will still include the
origin, I bet.


- Slime
[ http://www.slimeland.com/ ]
[ http://www.slimeland.com/images/ ]

Post a reply to this message

In article <3c40dcac$1@news.povray.org> , "Slime" <noo### [at] hotmailcom> 
wrote:

>> Because of your bounding threshold?  If you reduce the number below the
>> threshold the bounding will go away.
>
> Sorry, I'm not sure what a bounding threshold is...
>
> but maybe this will convince you: if you translate the shapes, their
> bounding boxes should move with them, right? Try translating them all by
> <1000,1000,1000> or something, and the bounding boxes will still include the
> origin, I bet.

I somehow get the impression you think I said the bounding boxes are tight.
However, with "While the bounding boxes can probably be changed for
efficiency" I wanted to express that they are in fact not as tight as
possible.  I am sorry I wasn't clear enough.  Either way, hopefully this is
fixed in the next beta, but as I don't have a lot of test scenes we will
just have to wait and see...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Slime" <noo### [at] hotmailcom> wrote in message
news:3c40dcac$1@news.povray.org...
> > Because of your bounding threshold?  If you reduce the number below the
> > threshold the bounding will go away.
>
> Sorry, I'm not sure what a bounding threshold is...

The number of objects in a scene it takes before automatic bounding takes
over, if so set in a INI.  Bounding_Threshold = 6

> but maybe this will convince you: if you translate the shapes, their
> bounding boxes should move with them, right? Try translating them all by
> <1000,1000,1000> or something, and the bounding boxes will still include
the
> origin, I bet.

I see that happening too (takes a large render for me to catch it before the
window draws over it), just not sure what to make of it.  I put a sphere
into a union with the sweeps but opposite of them to see if that would keep
the ordinary sphere's bounding box pinned to the origin too and it did not.
Not much of a test but just to see what would happen.

bob h

Post a reply to this message

Wasn't it Slime who wrote:
>but maybe this will convince you: if you translate the shapes, their
>bounding boxes should move with them, right? Try translating them all by
><1000,1000,1000> or something, and the bounding boxes will still include the
>origin, I bet.


Yes, they do still include the origin in the bounding box when
translated. 

        This scene

#declare This=sphere_sweep {
 linear_spline,
 2,
 40, 1
 50, 1
 translate <1000,1000,1000>
}

#debug "Min: <"
#debug str(min_extent(This).x, 3, 1)
#debug ", "
#debug str(min_extent(This).y, 3, 1)
#debug ", "
#debug str(min_extent(This).z, 3, 1)
#debug ">\nMax: <"
#debug str(max_extent(This).x, 3, 1)
#debug ", "
#debug str(max_extent(This).y, 3, 1)
#debug ", "
#debug str(max_extent(This).z, 3, 1)
#debug ">\n"

        Produces the output

Min: <0.0, 0.0, 0.0>
Max: <1051.0, 1051.0, 1051.0>

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

"Slime" <noo### [at] hotmailcom> wrote...
>
> Confirmation?

Yes.

This is the same bug that can cause radiosity to be calculated incorrectly
for sphere sweeps!  Note that setting Bounding_Threshold to zero in the INI
file (or command line) will "fix" the problem.

-Nathan

Post a reply to this message

In article <3c4208c0$1@news.povray.org> , "Nathan Kopp" <nat### [at] koppcom> 
wrote:

> This is the same bug that can cause radiosity to be calculated incorrectly
> for sphere sweeps!  Note that setting Bounding_Threshold to zero in the INI
> file (or command line) will "fix" the problem.

Ah, good to know that my change in beta 10 then corrected that bug.
However, why does radioity depend on a tight bounding box...?

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote...
> > This is the same bug that can cause radiosity to be calculated
incorrectly
> > for sphere sweeps!  Note that setting Bounding_Threshold to zero in the
INI
> > file (or command line) will "fix" the problem.
>
> Ah, good to know that my change in beta 10 then corrected that bug.
> However, why does radioity depend on a tight bounding box...?

You know, I don't really know.  That radiosity code is still a bit of a
mystery in some places.  All I know is that the bounding problems were
causing problems with radiosity, and fixing the bounding problems (by using
Bounding_Threshold=0) fixed the radiosity problems in my tests.

I just tested the latest version and it seems that the radiosity problem is
also now solved for sphere sweeps.

-Nathan

Post a reply to this message

Wasn't it Nathan Kopp who wrote:
>
>"Slime" <noo### [at] hotmailcom> wrote...
>>
>> Confirmation?
>
>Yes.
>
>This is the same bug that can cause radiosity to be calculated incorrectly
>for sphere sweeps!  Note that setting Bounding_Threshold to zero in the INI
>file (or command line) will "fix" the problem.

On my machine, setting bounding_threshold to zero causes scenes that
contain no objects to crash. [I wonder if this is the missing ingredient
which causes some people to have all their objectless scenes crash -
perhaps they have bounding_threshold=0 in their ini file for some
reason.]

It also doesn't "fix" the problem that the min_extent (or max_extent) of
the sphere sweep always includes <0,0,0>.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

In article <+cfY### [at] econymdemoncouk> , Mike Williams 
<mik### [at] nospamplease>  wrote:

> It also doesn't "fix" the problem that the min_extent (or max_extent) of
> the sphere sweep always includes <0,0,0>.

Yes, that is to be expected because the bounding box is an object property,
and bounding only makes additional use of this property, so it is always
available, regardless of the use of bounding boxes for acceleration.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message