Greetings,

Maybe a bit too early for povray.programming, so beta-test seems
appropriate.

I was diving in the beta.38 source lately(*²) (short of having the
beta.39 source at hand), and looking at the shapes objects code (in
particular sphere & plane). (source/backend/shape/spheres.cpp &
source/backend/shape/planes.cpp )

Both sphere & plane reimplement Intersect_BBox for their class as
"always true". (instead of ObjectBase::Intersect_BBox from which they
inherit). And that seems rather counter productive, as it seems to me
(but am I wrong ?) that the ObjectBase's implementation is fine
 (it checks the direction & side of the box).

It then seems to me that with the overloaded Intersect_BBox, the
Find_Intersection (from source/backend/scene/objects.cpp) will in fact
never (for plane & sphere) use the bounding box, but call the
::All_Intersections method (and that might be costly **) for each ray.

Did I miss a subtlety ( or more) ?



**: it seems that a lot of shapes like to change the method for "always
true", in effect removing the bounding box optimisation.

*²: I was looking for a strange memory expansion which seems to use
about a few bytes per pixel once the rendering has been started (and I
do not understand why, hence I'm searching), which occurs with an empty
scene (one camera), as well as a scene with 4 spheres (or finite 3D
objects) & one camera but not a scene with some planes (unless they
reduced to less into a csg-intersection, but then it's more a csg than a
plane).
It's very obvious with the gnome system monitor, and a huge resolution:
when povray starts, it allocates w*h*5 (let's say 9 GB for a square of
20500), and as the render progresses, it reach 16 GB (with a
quasi-linear progression within an empty scene). It also seems that the
release of that collection of memory takes some not so small time, as it
is done while the file is saved, and it might be sub-optimal (I do not
know yet what it is).

-- 
Real software engineers work from 9 to 5, because that is<br/>
the way the job is described in the formal spec.  Working<br/>
late would feel like using an undocumented external procedure.

Post a reply to this message

I don't know the source but a plane has an infinite bounding box. Also, 
maybe checking against a sphere is faster than checking a bounding box?

-- 
Tek
http://evilsuperbrain.com

"Le_Forgeron" <lef### [at] freefr> wrote in message 
news:4caf2856$1@news.povray.org...
> Greetings,
>
> Maybe a bit too early for povray.programming, so beta-test seems
> appropriate.
>

> beta.39 source at hand), and looking at the shapes objects code (in
> particular sphere & plane). (source/backend/shape/spheres.cpp &
> source/backend/shape/planes.cpp )
>
> Both sphere & plane reimplement Intersect_BBox for their class as
> "always true". (instead of ObjectBase::Intersect_BBox from which they
> inherit). And that seems rather counter productive, as it seems to me
> (but am I wrong ?) that the ObjectBase's implementation is fine
> (it checks the direction & side of the box).
>
> It then seems to me that with the overloaded Intersect_BBox, the
> Find_Intersection (from source/backend/scene/objects.cpp) will in fact
> never (for plane & sphere) use the bounding box, but call the
> ::All_Intersections method (and that might be costly **) for each ray.
>
> Did I miss a subtlety ( or more) ?
>
>
>
> **: it seems that a lot of shapes like to change the method for "always
> true", in effect removing the bounding box optimisation.
>

> about a few bytes per pixel once the rendering has been started (and I
> do not understand why, hence I'm searching), which occurs with an empty
> scene (one camera), as well as a scene with 4 spheres (or finite 3D
> objects) & one camera but not a scene with some planes (unless they
> reduced to less into a csg-intersection, but then it's more a csg than a
> plane).
> It's very obvious with the gnome system monitor, and a huge resolution:
> when povray starts, it allocates w*h*5 (let's say 9 GB for a square of
> 20500), and as the render progresses, it reach 16 GB (with a
> quasi-linear progression within an empty scene). It also seems that the
> release of that collection of memory takes some not so small time, as it
> is done while the file is saved, and it might be sub-optimal (I do not
> know yet what it is).
>
> -- 
> Real software engineers work from 9 to 5, because that is<br/>
> the way the job is described in the formal spec.  Working<br/>
> late would feel like using an undocumented external procedure.

Post a reply to this message

Le 08/10/2010 16:19, Le_Forgeron nous fit lire :
> I was looking for a strange memory expansion which seems to use
> about a few bytes per pixel once the rendering has been started (and I
> do not understand why, hence I'm searching)

Ok, as David Vincent (& the invaders), that memory expansion is not to
be found (it's not a leak). When the rendering threads are quicker that
the writing thread (the one which write the -state file when a file
output is needed), the consumed memory raises.

Typically, with +WT11 (on 12 core), on empty scene, with huge size to
render (a black picture anyway), the poor writing thread has a lot of
work that queue. Hence the memory raises.

If the render is slower (due to objects & textures), the raises is far
less. On slow enough scene, it's even flat.
(and notice: if the render start quick, the memory raises then lowers
once the rendering threads get to the slower parts).

That also explains why the activation/removal of MB does change the
memory profile: without MB, rendering is slower, so queue is shorter.

Post a reply to this message

Le_Forgeron <lef### [at] freefr> wrote:
> Both sphere & plane reimplement Intersect_BBox for their class as
> "always true". (instead of ObjectBase::Intersect_BBox from which they
> inherit). And that seems rather counter productive, as it seems to me
> (but am I wrong ?) that the ObjectBase's implementation is fine
>  (it checks the direction & side of the box).

  Calculating the intersection between a ray and a sphere is faster than
calculating the intersection of a ray and a (axis-aligned) box. Hence it
would make no sense to first check if the ray hits the bounding box of
the sphere and then if it hits the sphere. This would only make rendering
slower. It's much faster to just ignore the bounding box and always test
against the sphere directly.

  As for a plane, it would have an "infinite" bounding box, which would be
the plane itself. Hence checking if the ray hits this "bounding box" would
be completely identical to checking if the ray hits the plane itself. Hence
the useless "bounding box" check would only slow down the rendering of the
plane (because, basically, it would be calculating the ray-plane intersection
twice, when once would suffice).

-- 
                                                          - Warp

Post a reply to this message