POV-Ray : Newsgroups : povray.beta-test : sphere sweep bounding boxes calculated incorrectly Server Time
2 Nov 2024 07:25:22 EDT (-0400)
  sphere sweep bounding boxes calculated incorrectly (Message 1 to 10 of 15)  
Goto Latest 10 Messages Next 5 Messages >>>
From: Slime
Subject: sphere sweep bounding boxes calculated incorrectly
Date: 11 Jan 2002 17:44:02
Message: <3c3f6ab2$1@news.povray.org>
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

From: Slime
Subject: Re: sphere sweep bounding boxes calculated incorrectly
Date: 11 Jan 2002 17:46:15
Message: <3c3f6b37$1@news.povray.org>
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

From: Thorsten Froehlich
Subject: Re: sphere sweep bounding boxes calculated incorrectly
Date: 11 Jan 2002 18:07:07
Message: <3c3f701b@news.povray.org>
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

From: Slime
Subject: Re: sphere sweep bounding boxes calculated incorrectly
Date: 11 Jan 2002 21:54:17
Message: <3c3fa559$1@news.povray.org>
> 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

From: Mike Williams
Subject: Re: sphere sweep bounding boxes calculated incorrectly
Date: 12 Jan 2002 02:02:59
Message: <pBrN$DAaV6P8Ew0Y@econym.demon.co.uk>
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

From: Thorsten Froehlich
Subject: Re: sphere sweep bounding boxes calculated incorrectly
Date: 12 Jan 2002 06:48:04
Message: <3c402274@news.povray.org>
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

From: Slime
Subject: Re: sphere sweep bounding boxes calculated incorrectly
Date: 12 Jan 2002 20:02:36
Message: <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...

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

From: Thorsten Froehlich
Subject: Re: sphere sweep bounding boxes calculated incorrectly
Date: 12 Jan 2002 21:29:18
Message: <3c40f0fe@news.povray.org>
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

From: bob h
Subject: Re: sphere sweep bounding boxes calculated incorrectly
Date: 12 Jan 2002 21:30:38
Message: <3c40f14e$1@news.povray.org>
"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

From: Mike Williams
Subject: Re: sphere sweep bounding boxes calculated incorrectly
Date: 13 Jan 2002 01:15:53
Message: <tZpMZDAtRSQ8EwNE@econym.demon.co.uk>
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

Goto Latest 10 Messages Next 5 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.