[Radiance-general] Re: Octree blocks

[Greg Ward]

Hi Peter,

> From: Peter Apian-Bennewitz <apian@pab-opto.de>
>
>> 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.

Then use "xform" rather than instances.

>> 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 ?

I shouldn't have said "subcubes" when I meant "sub-boxes."  Ray
intersection tests in long, thin sub-boxes would be inefficient, and
the only way to make it efficient again is using a kd-tree, which
is more complicated to code.  I originally implemented cubical
octrees because they were simpler and just as fast as kd-trees
according to other people's research on the subject, and when
I added instances later, I was too lazy to reimplement everything
just so I could have non-cubical bounding boxes for instances.
I barely got it to work properly as it was -- you wouldn't believe
how much stuff is going on "behind the scenes" to make instancing
work right.  (Well, maybe you would.)

I wouldn't trust the octree code with long, thin boxes.  It's too likely
to run into floating point inaccuracies in extreme cases.  A lot of
the design of Radiance is based on my intuition of what will work
and what won't, and you're welcome to try things out
and prove me wrong.  I really don't mind, or take it personally.

-Greg