[Radiance-general] Octree blocks

[Peter Apian-Bennewitz]

Greg Ward wrote:

> An octree should have a few hundred geometric primitives to make it
> worthwhile in terms of rendering time.  Given such a constraint, it is
> usually
> possible to partition geometry so it is roughly cubical in terms of
> volume,
> though I agree this is an inconvenience. 
Geometry exported from CAD is often complex and uses Radiance primitives
not very efficiently, e.g. everything is tesselated into polygons, even
if the surface could be described as sphere, cone etc. Mostly
hierarchical structures are left intact, e.g. a line of complex carved
posts is known to the exporting routine as "instances" of the same
element.
Then, IMHO, there's no generaly sound way to reorganize geometry to fill
RADIANCE instances with cube like geometry.

> One could have an octree with a non-cubical bounding box, but the
> efficiency of tracing rays through long, thin subcubes would be awful.
If I get this right, the penalty for non-cubical bounding boxes with
non-thin geometry distribution would be nil, with the advantage that it
would allow placing "thinny" instances next to another without
overlapping bounding cubes. 
Code for checking ray intersections with non-cubical boxes would be as
efficient as checking cubical boxes ? If not, would that be
counterweight by the speedup as rays close to the bounding box miss the
non-cubical box completely whereas they hit (and trigger at least one
octree lookup) a cubical now ?

As always, any insights very much welcome
-Peter
-- 
 pab-opto, Freiburg, Germany, www.pab-opto.de